Skip to main content

HTTP Status Codes

Error Response Format

Every error response follows one JSON structure:

Error Codes Reference

The status column is the registry default; a route may return a different status for the same code via a per-call override.

Authentication Errors

AUTH_FAILED (401). The API key is invalid.
MISSING_API_KEY (401). The request has no Authorization header, or its Bearer token is empty.
ACCESS_DENIED (403). The API key is valid, but it has no access to this resource.

Validation Errors

VALIDATION_ERROR (400). The detail field holds an array of validation error objects.
INVALID_JSON (400)

Resource Errors

NOT_FOUND (404)

Rate Limiting

RATE_LIMITED (429). The response carries a Retry-After header.
Retry-After gives the number of seconds to wait before retrying, and appears only on a 429 response. Every successful response carries x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset for the tier that applies to that endpoint, extraction or general.

Server Errors

INTERNAL_ERROR (500, or 502/503 when the gateway passes an unstructured upstream failure through with its status)
GATEWAY_TIMEOUT (504)
Quote the request_id when you contact support; it is the sole correlation handle for an error.

Error Handling Best Practices

1. Check HTTP Status Codes

2. Use Error Codes for Logic

3. Implement Retry Logic

Use exponential backoff for the retryable errors: 5xx and 429.

4. Validate Before Sending

5. Log Errors for Debugging

Testing Error Scenarios

When building your integration, test these common scenarios: