Error response format
Every error response follows a consistent envelope structure:Error types
Error codes
Request ids
Every error response carries arequestId, and every response (error or not) carries the
same value in the X-Request-ID response header. Quote it when you report a problem: it
identifies the exact request in our logs.
If you send your own X-Request-ID header, we propagate it instead of generating one, so
your trace id and ours match.
Inside a batch account creation
response the per-item error object has no requestId. That call returns HTTP 200 and has
one id for the whole batch: read it from the X-Request-ID header.
Authentication failures vs. authentication outages
Two different situations used to look identical. They no longer do:authentication_required(401) means the key was rejected. Check the key, or rotate it. Retrying does not help.service_unavailable(503) on an authenticated endpoint means we could not reach the authentication service. Your key is fine. Retry with backoff.rate_limit_exceeded(429) means too many authentication attempts in a short window.
API key errors
API-key lifecycle failures reuse the standard codes above:- Invalid expiration — an
apiKeyConfig.validForDays(on account creation) or avalidForDays(on regeneration) outside the allowed range 1–365 is rejected withparameter_invalid(400). - Rate-limited regeneration — more than one regeneration for the same account within 2 minutes returns
rate_limit_exceeded(429). - Invalid or expired key — a revoked, unknown, or expired API key is rejected at authentication with
authentication_required(401) and the message “Invalid API key.” A missingAuthorizationheader returns the same code with the message “API key is required.” An expired key is not reported with a distinct code — it looks exactly like an invalid key, so rotate the account’s key to recover. - Publishable key used directly — a publishable (
pk_) key presented as a Bearer token to any endpoint returnspermission_denied(403): “Publishable keys cannot call the API directly…”. Publishable keys are exchange-only (browser embed); use your secret key for API calls. - Account creation requires an institutional key — a doctor-scoped key calling account creation is rejected with
permission_denied(403), notservice_unavailable. Use the institution’s key. See the example below.
CDSS review gate
GET /scribe-sessions/{id} and GET /medical-record-configurations are hard-blocked with
cdss_review_required (428) for a doctor-scoped API key when their institution has enabled
the CDSS pending-review gate and the doctor has at least one unreviewed CDSS suggestion within
the institution’s configured window (default 7 days). Institutional-scoped keys are never
gated. The response’s error.details.pendingConsultations array lists the blocking sessions,
each with a url pointing directly at the consultation in scribe-web where the doctor accepts
or rejects the pending suggestions — once every listed suggestion is reviewed, the same request
succeeds immediately (no caching).