> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Brand Onboarding
> One flow provisions a brand across six StateSet services — through the self-service portal at onboarding.stateset.com, the operator CLI, the provisioning API, or an MCP server so agents can onboard themselves.
Getting a brand live on StateSet is one flow, not six sign-ups. Onboarding provisions the brand
across every engine it needs, idempotently — run it twice and it creates only what is missing.
| Step | Service | What gets created |
| ---- | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| 1 | WorkOS | The brand's organization, with its domains |
| 2 | Knowledge Base (`kb.stateset.com`) | A collection with the brand's starter articles, embedded and ready to search |
| 3 | [ResponseCX](/api-reference/responsecx/overview) | The organization, its support rules, and the link to its knowledge base |
| 4 | [Temporal Engine](/api-reference/temporal/overview) | The brand in the workflow engine, on the ecommerce template |
| 5 | [NSR](/api-reference/nsr/overview) | The `ecommerce-returns` rulebook plus the brand's own rules — refund window, final-sale block, high-value review |
| 6 | [Voice](/api-reference/voice/overview) | A phone support agent and deterministic fast-answer sources (created unpublished by default) |
**Onboarding never invents your business rules.** Policy and article lists start empty; the
intake translator turns the plain-language policies *you* provide into KB articles, ResponseCX
rules and NSR clauses — and leaves blank what you leave blank.
## The portal — onboarding.stateset.com
[onboarding.stateset.com](https://onboarding.stateset.com) is the self-service path. The sequence
is built to be safe for a browser and for retries:
Brand identity, domains, support email, your shipping / returns / escalation / tone policies
in plain language, and which services to activate. No service-specific syntax anywhere.
The intake is translated deterministically into the exact provisioning plan — the KB articles,
rules and defaults it will create — with preflight results, before anything runs.
Approval freezes the configuration (drafts are revision-checked, so a stale tab cannot
overwrite a newer edit); launch is idempotent, so a retried click returns the original run
rather than provisioning twice.
Progress streams live, one line per service. Verification then probes all six services and
reports `present` / `absent` / `partial` for each — configuration drift shows up as
`partial`, and a re-run heals only what is missing.
Roles follow least privilege: a viewer reads, an editor drafts and previews, an approver
approves, launches, cancels and retries.
## The operator CLI
For operators with service credentials, the same pipeline is a command. It lives in the
`ss-onboard-agent` repository (not yet on npm) and reads the service keys from `.env`:
```bash theme={null}
onboard-brand init "Acme Outdoors" # scaffold brands/acme-outdoors.json — conservative defaults
onboard-brand check acme-outdoors # read-only: schema, credentials, completeness
onboard-brand acme-outdoors --dry-run # print every call without executing
onboard-brand acme-outdoors # provision; one line per service
onboard-brand verify acme-outdoors # probe all six services; exit 0 only when fully onboarded
onboard-brand acme-outdoors --only kb,response # re-run just the steps that need it
```
`check` separates launch-blocking errors (schema, credentials) from content warnings (an empty
knowledge base, no support rules). Every step is idempotent, so the retry story is always
`--only` the steps that failed. Add `--json` when a program is reading the output.
## The provisioning API
The portal is a client of a provisioning API you can also drive directly — asynchronous jobs, so
a web app can provision without holding service admin keys. The shape:
```text theme={null}
POST /v1/drafts create a resumable draft (brand config or plain-language intake)
PUT /v1/drafts/{id} autosave with { expectedRevision } — stale edits get a 409
POST /v1/drafts/{id}/approve preflight + freeze
POST /v1/drafts/{id}/launch idempotent launch → job
GET /v1/jobs/{id}/events SSE progress (Last-Event-ID supported)
GET /v1/brands/{slug}/verify read-only verification
```
Jobs run `queued → running → succeeded | failed | interrupted | cancelled`; `failed` means at
least one step failed — retry creates a new job for only the incomplete steps, with `retryOf`
lineage. Every job stores an immutable configuration snapshot with a SHA-256 hash, and audit
events are metadata-only: policy text, credentials and raw errors are deliberately excluded.
Terminal webhooks are available for success, failure and cancellation.
## For AI agents: the MCP server
The repository ships an MCP server so an agent can onboard a brand itself — the same six steps,
tool by tool:
| Tool | What it does |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `describe_requirements` | The brand-config JSON Schema, the six steps, and which credentials are present |
| `onboard_brand` | Provision — with `dryRun` and `only` for previews and partial runs |
| `verify_brand` | Read-only: what actually exists per service, `present` / `absent` / `partial` |
| `get_run_status` | A saved run's per-step results |
| `ingest_kb` | Embed and upsert knowledge-base articles |
| `deprovision_brand` | **Destructive** — tears down everything onboarding created, in reverse order; requires `confirm: true`, supports `dryRun` |
`deprovision_brand` deletes live configuration across six services. Give an agent this server
with the same care you would give it the keys — and prefer `dryRun` first, always.
## After onboarding
Onboarding is phase one of six —
[Launch a brand that runs itself](/guides/launch-a-brand-autonomously) is the whole path, from
this page to a brand operating autonomously with every control explained.
The five-minute ResponseCX quickstart, against the org onboarding just created.
The Voice agent was created unpublished — review it, then publish.
The NSR rules seeded at onboarding are what gate refunds; here is how a verdict works.
Connect Shopify, NetSuite and your 3PL through the Sync Server.