Skip to main content

Error response format

Every error response follows a consistent envelope structure:

Error types

Error codes

Request ids

Every error response carries a requestId, 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 a validForDays (on regeneration) outside the allowed range 1–365 is rejected with parameter_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 missing Authorization header 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 returns permission_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), not service_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).

Examples

Missing required field

Invalid API key

Resource not found

Consultation ID conflict

CDSS review required

Rate limit exceeded

Permission denied on account creation