Skip to main content
The Blockworks API uses conventional HTTP status codes. In general:
  • 2xx: the request succeeded.
  • 4xx: the request failed because of something in the request (a bad parameter, a missing key, a model you cannot access).
  • 5xx: something went wrong on our side. These are rare.

The error envelope

Errors use the same envelope as successful responses. On failure, error holds a human-readable message and data is null.
Check error before reading data. A non-null error always accompanies a non-2xx status code. Branch on the status code, and treat the message as a hint for humans: the wording can change.

Status codes

Every error message

The full set of messages the Data API sends, with the request that triggers each one.

Common errors

Unknown query parameter (400)

The API rejects any query parameter it does not recognize rather than silently ignoring it. This is deliberate: a typo in a filter name would otherwise return unfiltered data.
Filters always carry an explicit operator suffix: marketCapGte, not marketCap. There is no bare-field form. Check the model’s supported filters in the catalog or on the endpoint’s reference page.

Invalid filter value (400)

The value must parse as the column’s type.
Dates accept RFC3339, unix seconds, or YYYY-MM-DD.

Invalid time window (400)

timeframe and start/end are mutually exclusive, and each has its own accepted formats.
There is no year or month unit in relative windows. Use 365d, 52w, ytd, or a calendar period such as 2025 or 2025-06. See Granularity & time ranges for the full grammar.

Too many series (400)

A single ?series= request may name at most 20 series keys, and may not repeat one.

Authentication required (401)

The model is gated and the request carried no API key.
Confirm the X-Blockworks-API-Key header is present and the key is current. See Authentication.

Invalid key (403)

The key itself was rejected. The body is the gateway’s, not the API’s envelope message.
Check for a copy-paste error or a rotated key. A public model still returns 403 when the key sent with the request is invalid, so remove a stale key rather than leaving it in place.

Insufficient access (403)

Your key is valid, but the model is above your access tier.
Read access.tier for the model from the catalog to see what it requires. If you believe you should have access, contact support.

Not found (404)

Returned for an unknown model slug, an unsupported granularity for that model, or a tabular row identifier with no matching row.
Some timeseries models have too many series to return at once. For those, the all-series endpoint is unavailable and you must name the series you want:
The catalog’s allowAllSeries flag tells you which models support the all-series form.
A timeseries request never returns 404 for an unknown series key. It returns 200 with "points": [] and no entity. If a series comes back empty, check that the key is the lookup table’s primary key (a UUID for assets and networks), not a slug or a symbol. See Finding an id.

Server errors (500)

These indicate a problem on our side. We monitor for them, but reports help. Include the X-Request-Id response header from the failing call when you contact support; it lets us find the exact request.