Provision a registry workspace
Provisions a complete CONFIRM workspace for one of your registries: the organization, its cloned AI screening agent, and registry-branded candidate messaging. Call it when a business is created on your side, or when they enable recruiting.
Returns the workspace identifier — the one-per-business value you store and use to recognise and build CONFIRM links.
Idempotent on external_ref: calling it again returns the existing
workspace with created: false and the same body, so your job never has
to branch on whether it has run before.
A dedicated phone number with caller-ID registration is provisioned separately by CONFIRM, since it requires carrier registration that cannot complete synchronously.
A new workspace has no calendar, so its screening calls are held.
The response carries calendar.connected. While it is false,
warnings says so and screening calls in the workspace wait. Send a
calendar-connect link with
POST /organizations/{ref}/calendar-invite;
held calls go out once a calendar is connected. See the
calendar guide.
Authentication
Partner API key sent as Authorization: Bearer cfk_.... Keys are partner-level — one key reaches every registry linked to your partner account and nothing else. CONFIRM issues and revokes them; a key is shown exactly once at creation because only its hash is stored, and revocation takes effect on the next request. Develop against the sandbox base URL with a sandbox key, where telephony is restricted to an allowlist you provide.
Request
Your registry/business identifier. The key this workspace is correlated on, forever.
Display name of the registry. Appears in the portal and in candidate-facing messaging.
Sandbox only. Which CareLink auth server this workspace’s users sign in against. Omit it to use the default (your staging auth server in sandbox). auth: null and auth: {} both mean the default sign-in server, the same as sending base_url: null. In production it is ignored with a warning, since production workspaces always use the production auth server.
Response headers
The ID of this request. On an error it equals request_id in the body. If you sent an X-Request-Id, it is your value, returned unchanged. Log it, and quote it when contacting CONFIRM support.
Response
Workspace provisioned. Posting an external_ref that already exists returns 200 with the same workspace and created: false, so replays never create a second workspace.
Your registry/business identifier, echoed back.
The workspace identifier — store this per business. It is the {workspace} segment of every CONFIRM deep link.
False when the registry was already provisioned and this call was a no-op.
Present when the workspace has its own auth server (sandbox), on both POST and GET. A POST that sent auth always echoes it, with base_url: null when the workspace is on the default server.
Whether the workspace has a connected calendar, on both POST and GET. Screening calls in the workspace are held while connected is false; connect one with POST /organizations/{ref}/calendar-invite. Left out on the rare response where the check itself could not be made, rather than guessing.
Non-fatal notes about the provisioning run, when any apply (POST only). Includes a note that screening calls are held while the workspace has no connected calendar.

