Skip to main content

HTTP Status Codes

Error Response Format

All error responses follow a consistent JSON structure:

Error Codes Reference

Authentication Errors

AUTH_FAILED (401) — Invalid API key
ACCESS_DENIED (403) — Missing API key or insufficient permissions

Validation Errors

VALIDATION_ERROR (400) — The detail field is an array of validation error objects:
INVALID_JSON (400)

Resource Errors

NOT_FOUND (404)

Processing Status

PRECONDITION_FAILED (412) — Results not yet available. The retryable flag indicates whether to continue polling:
  • retryable: true — processing is still running. Poll again with backoff.
  • retryable: false — processing reached a terminal failure (error or cancelled). Stop polling.

Terminal Extraction Failures

Returned by GET /v2/workflows/{workflow_id}/files/{collection_id}/results/ when the extraction reached a terminal state. Polling will not transition the collection out of these states — stop polling and surface the failure to the caller. EXTRACTION_FAILED (422) — The extraction job did not complete successfully.
EXTRACTION_CANCELLED (422) — The extraction job was cancelled.

Rate Limiting

RATE_LIMITED (429) — Response includes Retry-After header
Rate-limited responses include a Retry-After header indicating how many seconds to wait before retrying. All successful responses include x-ratelimit-limit, x-ratelimit-remaining, and x-ratelimit-reset headers showing the limit for the tier that applies to that endpoint (extraction or general). The Retry-After header is only present on 429 responses.

Server Errors

INTERNAL_ERROR (500/502/503)
GATEWAY_TIMEOUT (504)
Server errors (500) include a reference_id field. Use this ID along with the request_id when contacting support to help identify and resolve the specific issue.

Error Handling Best Practices

1. Check HTTP Status Codes

2. Use Error Codes for Logic

3. Implement Retry Logic

For retryable errors (5xx, 429, 412), implement exponential backoff:

4. Validate Before Sending

5. Log Errors for Debugging

Testing Error Scenarios

When building your integration, test these common scenarios:

Framework-Level Errors

While most errors use the structured { "error", "detail", "error_code", "retryable", "request_id" } format, some framework-level responses (e.g., unknown URL path) may return a simpler format: