Skip to content
vocapable.Docs

Error registry

Every non-2xx response from the API is an RFC 9457application/problem+json body whose type URI points at a page in this registry at https://docs.vocapable.com/errors/{code}. The code is stable and machine-matchable: a changed meaning is a new code, never a re-pointed one. Branch on the code alone and treat the status as redundant confirmation. How to handle problems: see theerror-handling guide. Every code below is an anchor on this page (/errors#{code}) and links to its own page.

Two families of 5xx are worth knowing before you retry anything:503 means this deployment is missing a dependency it needsThe request may succeed later or on another environment. 501means the code path is not implemented here and retrying will never help until it ships. Neither is ever the caller's fault.

9.1 Transport, authentication, and tenancy

Raised on every surface, ahead of any resource logic.

9.2 Request shape: validation, filtering, pagination, idempotency

9.3 Agents, templates, knowledge packs, voice profiles

9.4 Contacts, lists, and imports

9.5 Campaigns, scrubbing, consent, and DNC

9.6 Calls, analytics, billing, and exports

9.7 Telephony accounts, phone numbers, and pools

9.8 Messaging, calendar, and webhooks

9.9 Non-customer surfaces

The /internal audience (the voice runtime's synchronous calls, authenticated by a service credential) and the telephony provider callbacks are excluded from the customer OpenAPI document and are not part of the public contract. They emit the same problem shape, and their codes are registered here so an operator reading a log line has one place to look.

9.10 Agreements

GET /v1/agreements includes an additive nullable markdown field per document. The current registry supplies the exact UTF-8 source bytes identified by content_sha256, allowing the portal to display every document before its acceptance.

9.11 First-party accounts and browser sessions

The portal's own sign-in. Sign-in refuses with one body for every reason - unknown email, wrong password, and a disabled account are invalid_credentials alike, because a per-reason message is an account-existence oracle on a surface with no credential to rate-limit against.

9.12 Account deletion

The verified, non-destructive account-deletion request/status path (/v1/account-deletion), one of the three session-cookie customer surfaces rather than a key-reachable one. A request opens a reviewable record; it does not erase a workspace or its call, billing, and compliance records.

9.13 Mobile companion app (receptionist)

Company-wide agent authoring adds GET /v1/mobile/agent-knowledge, POST /v1/mobile/agents, and POST /v1/mobile/agents/{agent_id}/clone. All require the Admin-only AGENT_DRAFTS_WRITE capability and workspace_hub admission.

9.14 Caller requests and the inbox

GET /v1/inbox also accepts equality filters agent_id and campaign_id, and created_at.lt for an exclusive upper bound. Existing created_at.lte remains inclusive.

9.16 The customer team workspace (`/v1/workspace/*`)

The customer's own CRM, worked by named people: every route requires the workspace:work scope and a console key that names a person (console_user_id); an integration key is refused with workspace_person_required even when it holds the scope. The company is the key's tenant; the role (owner / manager / rep) comes from the membership the key was minted under and decides every capability server-side.

9.17 The customer team workspace on the phone (`/v1/mobile/workspace/*`, `/v1/mobile/voice/token`)

The native app reaches the same workspace records through thin wrappers authenticated by the mobile bearer (never a console key): the mobile role's capability (workspace_crm:read, workspace_crm:write, workspace_approvals:review, workspace_exceptions:read, workspace_integrations:read, workspace_calls:embedded) gates the native surface (mobile_capability_forbidden), and the workspace role mapped from the membership (admin → owner) decides every record exactly as §9.16 describes, with the same codes.

9.18 The integration hub (`/v1/workspace/integrations/*`)

Reading the catalog, installations, activity and conflicts is open to every person in the company (a rep's Connections tab is view-only); every change needs manage_integrations (owner or manager).

9.19 Business mail and messaging

Email replies leave through the company's own Gmail or Outlook connection: POST /v1/workspace/inbox/threads/{contact_id}/email-replies saves one for review (an approval pins the exact recipient, mailbox, subject and body), the shared /inbox/replies/{id}/review route approves it, and /inbox/replies/{id}/send spends the approval once and queues ONE provider send (operation key = the reply's send key).

9.20 Meetings and appointments (`/v1/workspace/meetings*`, `/v1/workspace/agenda`)

A meeting is the company's commitment to one of its customers at a time, with a responsible host. Reading is scoped like customers (a rep sees meetings they host and those on relationships they may open); a rep hosts only themself.

9.21 CRM sync and Apollo lead intake (`/v1/workspace/integrations/crm/*`, `/apollo/*`)

A CRM's sync plan (direction, field groups with the email match locked on, who wins owner and stage conflicts, stage mapping), its health, its conflicts and the deal changes and call logs waiting for review are readable by everyone in the company; every change needs manage_integrations. Apollo search and enrichment need bulk_import, and spending credits needs a confirmation of the exact estimate.

9.22 Contact center (`/v1/workspace/contact-center/*`, `/v1/workspace/me/agent-state*`, `/v1/workspace/quality/*`, teams/roles/SSO/SCIM)

One section for the contact-center layer.

9.23 Existing company agent setup

This index lists the codes an API key can receive. Codes raised only on the staff console or on internal runtime surfaces keep their own pages so every typeURI resolves, but are not listed here. The index and every code page are regenerated from the registry of record on each build; the build fails if they diverge.