code values you can branch on, and which failures are safe to retry.
Rely on the status first and on code when it is present, because the text of a message can change.
Status codes
Error bodies
Error bodies do not share one envelope, so read them defensively. The shape depends on the endpoint family:
A
500 may have no JSON body at all, so handle a body that does not parse.
API key errors
For a few minutes after an application is deleted the API answers with
application_deleted, and after that it refuses the key like any wrong key.
Do not retry: the application and its keys are gone.
See API authentication and API keys for how keys and their limits work.
Not enough credits
Each API family reports a low balance in its own way:
On a contract, a session create answers
403 with "code": "contract_billing_suspended" while paid services are paused for your organization.
Sandbox applications are never billed, so they skip these checks.
Error codes
Thesecode values are stable, so you can branch on them.
Most sit next to detail; on Digital ID wallet verification the code is the value of error.
Access and billing
Requests and idempotency
Bank, phone and risk checks
Business verification (KYB)
Digital ID wallets
Reports and cases
Electronic signatures
On session create, the document problems below arrive as the value of the offending field with status
400, for example {"sign": "signature_document_changed"}:
Webhooks
Retries and idempotency
Some failures are safe to repeat and some are not:429: wait for theRetry-Afterheader, then retry.502and503: retry with backoff when the endpoint’s reference says nothing was billed, as it does for phone, email, bank and risk checks.502onPOST /v3/database-validation/: read eachvalidation_errorsentry first, because this status alone does not mean a temporary failure.503on a deletion: repeat the same request until it returns200.- Other
4xx: fix the request first, because the same request fails the same way.
POST /v3/aml/ and Digital ID wallet verification accept an Idempotency-Key header of up to 255 characters.
Repeating a request with the same key and body replays the stored response, so the work and the charge run once.
The same key with a different body answers 409, and while the first request is still running the wallet endpoints answer 409 with Retry-After.
POST /v3/session/ has no idempotency key, so if a create times out, list your sessions by vendor_data before creating another one.
Related
- Rate limiting: limits, headers and the
429body. - API authentication: how to send your key.
- Sandbox testing: reproduce outcomes without real data or billing.
- Webhooks: delivery, retries and order.