Org Blueprints

Blueprints package reusable GoodQA configuration in goodqa.blueprint/1 JSON. They are dark by default: blueprints.enabled must enable the org before any route or MCP tool appears. Settings > Blueprints is shown only after the server confirms administration access. Export selected configuration, download a saved file, upload it in a target organization, preview its field diffs and ID mapping, then apply with skip, rename or compatible override. The page reports every item outcome and links to the application audit.

An org admin exports selected configuration using POST /v1/orgs/{orgId}/blueprints/export, transfers the file to a target org, then calls POST /v1/orgs/{orgId}/blueprints/plan. The plan shows field diffs, conflicts, target IDs and warnings. A new target ID is null until apply.

Apply names the returned planId, exact planSha256, and conflictPolicy: skip, rename, or override. Safety conflicts cannot be overridden. Each item commits with its audit receipt, so a partial application can be retried without duplicating completed items. Configuration changed after planning requires a fresh plan. A new body needs a new blueprint version.

A signed-in person may apply directly. For MCP, that person first uses POST /v1/orgs/{orgId}/blueprints/approve with the exact plan, conflict policy and apiKeyId. The key passes the returned approvalId to blueprint_apply within 15 minutes. Both the key owner and approver must still have permission. Keys cannot approve themselves. blueprint_export, blueprint_plan, and blueprint_applications use the same org administration and config gates. Keys also need the native CRM, chat or outreach family and API-access switch for each selected kind; an org-only key cannot borrow those capabilities.

The nine baseline v1 kinds are crm.pipeline@1, crm.field@1, crm.tag@1, crm.flag@1, crm.lifecycle@1, chat.channel@1, outreach.template@1, form@1, and scheduling.event_type@1. The registry also carries crm.segment@1 and crm.lifecycle_rule@1 (eligibility only) from the existing CRM module, plus routine@1, form.crm_mapping@1 and outreach.sequence@1. A form mapping names its form, tags, flags, pipeline stage and lifecycle by name and lands switched off; a sequence names templates a person has already approved and enrols nobody. Kind schemas are published in the all-features OpenAPI under x-goodqa-blueprint-kind-schemas.

With chat.lines enabled, chat.line@1 adds portable custom chat line templates. Export/plan require org:manage_agents and the chat family in addition to blueprint administration. A signed-in person must apply these recipes, including those without personas; the key-approval path above does not apply to this AI configuration kind. No runtime identities or live channels are copied, and rail increases or changes to line kind/persona presence require manual resolution.

No customer records, messages, memberships, files, credentials, webhooks, mailboxes, domains, billing or provider accounts are copied. Secret-shaped text fails export and import in raw and rendered Markdown spellings. Templates and forms land as drafts. Scheduling definitions are inactive and have no hosts; a person configures them separately before publishing. Lifecycle guards/actions and project-scoped forms/channels are outside the portable v1 format. Existing channel privacy cannot change. Policy cannot be loosened: field types, removed options/stages and flag applicability or exclusivity changes require manual handling. The file holds at most 100 items, 4 KiB each, and 512 KiB overall.

See the design and all-features OpenAPI. The org applications API returns the newest 100 readable immutable receipts, including who applied each item. Library exports require access to every stored kind; ledger receipts are filtered per kind. Native permissions, credential families and entitlements are checked before the 100-row limit. Settings reads the optional blueprintsEnabled org marker from /me; when absent, it makes no Blueprint request.

API reference: enabled routes appear in /v1/openapi.json; dark schemas are in the all-features document above.
MCP tools: MCP tool reference.
Runbook and design: Blueprint workflow, permissions and limits.

Routine workflows additionally use routine@1. Imports require the live org owner and routines.enabled, land disabled, and copy no project, person bindings or run data. See Routines.

Read routes for the UI: GET /v1/orgs/{orgId}/blueprints (newest 100 readable exports), GET .../blueprints/{blueprintId} (same-org stored file), and GET .../blueprints/configurations/{kind} (labels and exportability only, native kind permissions required). Sensitive labels are redacted and incompatible configuration cannot be selected. Catalog item keys derive from normalized configuration identity, so they remain stable after target IDs are remapped. There are no public sharing links.

Commercial services example is synthetic configuration: no contacts, payment accounts or sending authority. Billing connections and recurring payment setup remain outside the file.

Org Blueprints

API reference: enabled routes appear in /v1/openapi.json; dark schemas are in the all-features document above.

MCP tools: MCP tool reference.

Runbook and design: Blueprint workflow, permissions and limits.

Routine workflows additionally use routine@1. Imports require the live org owner and routines.enabled, land disabled, and copy no project, person bindings or run data. See Routines.

Commercial services example is synthetic configuration: no contacts, payment accounts or sending authority. Billing connections and recurring payment setup remain outside the file.

Org Blueprints

API reference: enabled routes appear in /v1/openapi.json; dark schemas are in the all-features document above.
MCP tools: MCP tool reference.
Runbook and design: Blueprint workflow, permissions and limits.

Routine workflows additionally use routine@1. Imports require the live org owner and routines.enabled, land disabled, and copy no project, person bindings or run data. See Routines.

Commercial services example is synthetic configuration: no contacts, payment accounts or sending authority. Billing connections and recurring payment setup remain outside the file.