> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate limits

> Each 0xArchive plan's request rate, concurrent queries, monthly credits, WebSocket and replay capacity, and how to handle a 429 response.

Every plan, Free included, can call every route and subscribe to every WebSocket channel except one: the live [`mempool`](/websocket/mempool) channel, which comes with the Pro, Scale and Enterprise plans. Otherwise, plans differ in capacity: how many requests you can send each second, how many can run at once, how many credits you can spend in a month, and how much WebSocket and replay capacity you get. Prices and checkout are on the [pricing page](https://0xarchive.io/pricing).

## Requests

| Plan | Requests |
| - | - |
| Free | `15` requests per second<br />`3` concurrent queries<br />`50,000` API credits a month |
| Build | `50` requests per second<br />`10` concurrent queries<br />`80M` API credits a month |
| Pro | `150` requests per second<br />`20` concurrent queries<br />`400M` API credits a month |
| Scale | `500` requests per second<br />`20` concurrent queries<br />`2B` API credits a month |
| Enterprise | From `1,000` requests per second<br />From `500` concurrent queries<br />Unlimited API credits |

What a request costs in credits is on [Credits](/core-concepts/credits).

## WebSocket and replay

| Plan | WebSocket and replay |
| - | - |
| Free | `10` subscriptions per connection, `2` connections<br />`10x` standard replay |
| Build | `500` subscriptions per connection, `3` connections<br />`50x` standard replay |
| Pro | `3,000` subscriptions per connection, `5` connections<br />`100x` standard replay |
| Scale | `20,000` subscriptions per connection, `16` connections<br />`300x` standard replay |
| Enterprise | Unlimited subscriptions and connections<br />`1,000x` standard replay |

Each connection accepts at most 10 subscribe or unsubscribe operations per second. [WebSocket limits](/websocket/limits) shows how to size a client to these numbers.

## History

| Plan | History |
| - | - |
| Free | Most recent 30 days; max 30-day request span |
| Build | Full retained archive |
| Pro | Full retained archive |
| Scale | Full retained archive |
| Enterprise | Full retained archive; contract-specific terms |

Free serves the most recent rolling 30 days, and one request or replay can span at most 30 days. Build and above keep the full retained archive, so the first served date of each dataset sets how far back a request can reach. [Free tier](/core-concepts/free-tier) has the rest of the Free plan.

## Export credits and Webhook Alerts

| Plan | Export credits and Webhook Alerts |
| - | - |
| Free | No export credits<br />No webhook delivery; the estimate and dry-run previews still answer for supported event types |
| Build | `$50` of export credits a month<br />1 endpoint, 8 rules, 5,000 deliveries a day |
| Pro | `$300` of export credits a month<br />4 endpoints, 40 rules, 50,000 deliveries a day |
| Scale | `$1,500` of export credits a month<br />12 endpoints, 200 rules, 500,000 deliveries a day |
| Enterprise | Custom export credits<br />Custom webhook allowance |

Export credits reduce the cost of file exports, which are priced per order; see [Exports](/exports#how-buying-works). Unused export credits roll over, as [Credits](/core-concepts/credits) explains. The webhook allowance covers endpoints, rules, watched wallets and deliveries a day. Deliveries are counted per account across every endpoint and do not use API credits, and a rule that crosses the daily allowance pauses until you resume it; see [Webhook Alerts](/webhooks).

## When you reach a limit

Every metered REST response carries your current position in its headers: `x-ratelimit-limit`, `x-ratelimit-remaining` and `x-ratelimit-reset` for the per-second limit, and `x-credits-limit`, `x-credits-used`, `x-credits-remaining` and `x-credits-reset` for monthly credits. Reset values are Unix seconds.

A `429` is not always worth retrying. Read its `error_code`, and the field beside it, before you decide:

* **Request rate:** `429`, `error_code` `rate_limited`, and `retry_after`, the seconds to wait. Wait that long, then retry at a lower request rate, within a fixed retry budget.
* **Concurrent queries:** `429`, `error_code` `rate_limited`, and `max_concurrent`, your plan's limit. There is no wait value: retry when one of your in-flight requests finishes, within the same budget, and cap your worker pool at the limit.
* **Monthly API credits:** `429`, `error_code` `insufficient_credits`, with `credits_used` and `credits_limit`. Stop the job. A retry cannot succeed until credits reset at `x-credits-reset` or the plan changes.
* **Temporary unavailability:** `503` with a `Retry-After` header. Wait that many seconds and retry within the budget.
* **WebSocket subscriptions:** a subscribe beyond the plan's limit gets an `error` message with `error_code` `rate_limited`. Unsubscribe from something first; a retry of the same subscribe fails the same way.
* **Mempool channel on Free or Build:** a `mempool` subscribe gets an `error` message with `error_code` `forbidden`. A retry cannot succeed until the plan changes to Pro, Scale or Enterprise.
* **Standard replay speed:** a replay that asks for more than the plan's speed runs at the plan's speed. Nothing to retry.

If a response you can retry carries no wait value, use capped exponential backoff with jitter and lower concurrency. Keep the request ID of every failed attempt: the top-level `request_id` in the error body, or the `x-request-id` header. Do not retry an authentication, malformed-request, unsupported-symbol or invalid-parameter error unchanged; fix the request first. [Errors](/errors) lists every status code and `error_code`.

## Design clients around limits

Build clients as queues, not as unbounded loops. A historical job that knows its route, symbol, time window, page size, concurrency and retry budget before it starts can pause, resume and explain a run without duplicating data.

<Steps>
  <Step title="Start with one symbol and one route">
    One BTC order-book request confirms authentication and the response shape. One one-hour trade window confirms pagination, latency and the output schema.
  </Step>

  <Step title="Split long pulls into windows">
    Retry or resume each window on its own, from its saved cursor, so one failure does not restart the whole job.
  </Step>

  <Step title="Keep heavy and light work apart">
    Run L3, L4, replay and long-history jobs in their own bounded worker pool, so one slow request cannot block freshness checks.
  </Step>

  <Step title="Set stop conditions">
    Stop or pause on a rate-limit response that persists, a credit threshold, stale data, a gap event or consumer lag, and record why the run stopped.
  </Step>
</Steps>

For WebSocket clients, limits interact with processing speed. A client that receives data faster than it can process it produces stale dashboards, bad local books or dropped replay messages even when the server accepts every subscription.

## Next step

Run one bounded job inside these limits with the [Limits and throughput guide](/guides/limits-and-throughput).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.