Skip to main content
Errors use the same envelope as successful responses, with data: null and an error object describing what went wrong:
code is stable and safe to match on. message and hint are human-readable and may evolve. docs points to the relevant guide. For list endpoints, the envelope also includes pagination with limit, has_more: false, and next_cursor: null so the response shape stays consistent on error.

HTTP status codes

Common error codes

Resource-specific codes

Sessions

Verify (public endpoints)

These appear when the verify web app or a mobile client talks to /v1/verify/*. You’ll usually only see them in user-facing error states, not in your own server code.

Webhooks

What to retry

5xx and transient network failures are safe to retry on idempotent operations (GET, DELETE, POST /cancel). Every POST /v1/sessions produces a brand-new session — retrying after a 5xx may create a duplicate. Use a request-side idempotency check (last response captured before the timeout) before re-issuing creates. 4xx responses other than 429 (which the API does not currently emit) are permanent — fix the request shape rather than retrying.