Errors
The API uses conventional HTTP status codes and returns a JSON body with an error field (and sometimes a message) on failure.
Status codes
Common error bodies
Asynchronous failures
A 202 Accepted from create verification only means the request was queued. The verification can still finish as failed, not_found, or error. Those are not HTTP errors: read them from GET /status/:id or the verification.* webhooks.
Each non-success outcome carries a human-readable reason plus a stable reasonCode you can branch on (e.g. document_expired, selfie_mismatch, identity_not_found). The full catalogue is in failure reason codes.
Health check
A public, unauthenticated endpoint for uptime monitoring.
Handling errors well
- Retry
429,502,503,504and connection failures with backoff and the same idempotency key. Do not blindly retry every500: preserve its request ID and contact support if it persists. - Treat
4xx(except429) as non-retryable: fix the request; retrying unchanged will fail again. - Always read the
error/messagefields; don’t rely on status code alone.
Server SDK errors (package preview)
The server SDK is not yet available on the public npm registry. For current integrations, handle the HTTP status and error code as described above. When the package is published, its typed errors will let your backend branch without parsing messages:
Transaction and activity decisions fail closed when credit is unavailable; a
late record is not an authorisation response. A paused customer risk assessment
sets InsufficientCreditError.pending or returns pending_credit, keeps the same
resource and resumes after funding. Do not submit a duplicate.