Developers /Documentation

Errors & retries

Use stable error codes to understand failures and decide what to do next.

Error response

Errors include a human-readable message and a stable code. Some errors include a details object.

Illustrative error

{
  "success": false,
  "error": "missing API key: send Authorization: Bearer <key>",
  "code": "unauthorized"
}

Status codes

HTTP	Code	What to do
`400`	`invalid_request`	Check the request fields.
`401`	`unauthorized`	Check the key and its scopes.
`402`	`insufficient_credits`	Review the account allowance.
`403`	`target_blocked`	Inspect the policy or network block reason.
`404`	`not_found`	Check the resource ID and account.
`408`	`timeout`	Review the source and request timeout.
`413`	`payload_too_large`	Reduce the document size (Docs).
`415`	`unsupported_document`	Use a supported document (Docs).
`422`	`target_failed / watch_unresolved / document_failed`	Inspect the source or document error details.
`429`	`rate_limited`	Wait according to Retry-After.
`503`	`unavailable`	Retry later with backoff.

Schema-validation responses may also use HTTP 422 with a validation detail array.

Retry behavior

For rate limits, respect the Retry-After header. Use bounded exponential backoff for temporary availability failures. Correct invalid requests and authorization failures before retrying.

For a timed-out job creation request, check existing jobs before creating another one. Do not assume retries are idempotent.

FactGet developer documentationExplore the quickstart