Skip to main content
Every error the API raises has the same body:
The HTTP status always matches the code. Two responses come from the HTTP layer instead, with no JSON body: a request with the wrong method for its path gets 405 Method Not Allowed, and a request to /v1/stream without WebSocket upgrade headers gets a plain-text 4xx.

Error codes

CREDITS_EXHAUSTED and FORBIDDEN are reserved. No key receives them today.

Validation details

A VALIDATION_ERROR lists each problem by field, as in the example at the top of this page. field is the parameter’s name as you sent it, or path, query or body when the problem is not tied to one field.

Three causes of 429

See Rate limits and headers for the numbers.

Retry strategy

  1. Honour Retry-After. Every 429 carries it, in whole seconds. Wait at least that long.
  2. Back off exponentially on 500 and 503, with jitter, so parallel workers do not retry in step.
  3. Cap your retries. Three to five attempts are enough. Past that, the problem needs attention.
  4. Never retry a 4xx other than 429. It fails the same way every time.

Request IDs

Every response carries an X-Request-ID header. You can also send your own X-Request-ID: up to 128 visible ASCII characters, with no spaces. The API echoes it back. It replaces any other value with a generated ID rather than rejecting the request. When you contact support about a failed request, include its X-Request-ID.

Errors on streams

A refused stream frame gets an error frame with the same code, message and details. See Connecting to streams.

New codes and fields

The API evolves without breaking your integration:
  • New error codes can appear. If you meet a code you do not recognize, handle the response by its HTTP status.
  • New response fields can appear. Ignore fields you do not recognize.
  • Codes are never renamed, repurposed or removed within a version.