Skip to main content
The Didit API reports a failure with an HTTP status code and, in almost every case, a JSON body. This page lists what each status means, what the body looks like, which 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

These code 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 the Retry-After header, then retry.
  • 502 and 503: retry with backoff when the endpoint’s reference says nothing was billed, as it does for phone, email, bank and risk checks.
  • 502 on POST /v3/database-validation/: read each validation_errors entry first, because this status alone does not mean a temporary failure.
  • 503 on a deletion: repeat the same request until it returns 200.
  • 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.
Last modified on October 31, 2026