> ## 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 and credits

> Understand 0xArchive request rates, concurrency, credits, plan gates, replay limits, and retry behavior before high-volume jobs.

Plan limits define how fast a client can call 0xArchive and how much it can pull each month. Treat the live pricing page and any response headers returned for your account as account-specific signals for your key.

Plan limits affect monthly credits, request rate, concurrency, WebSocket scale, replay speed, and export volume, not which endpoints, markets, or data types you can call. Every route, market family, and schema is available on every tier, including Free.

## Current Public Plans

Use the pricing page for checkout, billing-period switches, and account-specific terms. The public pricing page exposes both monthly and annual billing and currently defaults to annual billing; use this table while designing clients and queue capacity. For starter/free fit checks, use [Free tier](/core-concepts/free-tier).

Every new account starts on the [Free tier](/core-concepts/free-tier), no card required. Upgrade when you need higher limits.

|                              | Free                        | Build                            | Pro                               | Scale                             | Enterprise                         |
| ---------------------------- | --------------------------- | -------------------------------- | --------------------------------- | --------------------------------- | ---------------------------------- |
| Monthly price                | `$0`                        | `$49`                            | `$199`                            | `$799`                            | Custom                             |
| Annual price (billed yearly) | `$0`                        | `$39/mo`                         | `$159/mo`                         | `$639/mo`                         | Custom                             |
| Monthly API credits          | `50,000`                    | `80M`                            | `400M`                            | `2B`                              | Unlimited                          |
| Requests per second          | `15`                        | `50`                             | `150`                             | `500`                             | from `1,000`                       |
| Concurrent queries           | `3`                         | `10`                             | `20`                              | `20`                              | from `500`                         |
| WebSocket subscriptions      | `10`                        | `500`                            | `3,000`                           | `20,000`                          | Unlimited                          |
| Replay speed                 | `10x`                       | `50x`                            | `100x`                            | `300x`                            | from `500x`                        |
| Data Catalog credits         | none                        | `$50/mo`                         | `$300/mo`                         | `$1,500/mo`                       | Custom                             |
| Best fit                     | Fit checks and auth testing | Notebooks, dashboards, backtests | Production systems, heavier usage | High-throughput, large WS fan-out | Dedicated throughput, custom terms |

Every tier, including Free, gets every market family (Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, and Lighter), every schema (L2/L3/L4 order books, order flow, TP/SL), and the full archive. Higher tiers raise credits, request rate, concurrency, WebSocket subscription caps, and replay speed; Enterprise adds dedicated throughput, custom retention, contractual review, and customer-facing terms.

## Data Catalog Export Pricing

Use the Data Catalog when the job is a file purchase instead of a recurring API workload.

| Dataset family            | Public price | Minimum           |
| ------------------------- | ------------ | ----------------- |
| L4 Order Book / L4 Orders | `$8/GB`      | `$25 minimum`     |
| Trades / Liquidations     | `$8/GB`      | `$15-$25 minimum` |
| L2 / L3 Order Book        | `$6/GB`      | `$10 minimum`     |
| Funding / Open Interest   | `$1/GB`      | `$5 minimum`      |

Subscriber credits apply before card charge. Volume discounts start at `$500+`.

## How Limits Work

| Control             | What it affects                                           | Client behavior                           |
| ------------------- | --------------------------------------------------------- | ----------------------------------------- |
| Requests per second | Burst rate across REST calls                              | Use backoff and queuing                   |
| Concurrent queries  | Long-running or heavy history calls                       | Bound worker pools                        |
| Credits             | Data volume and heavy route cost                          | Budget by endpoint and time range         |
| Route gates         | Higher-depth history, L3/L4, replay, and advanced tooling | Verify route access before production use |

## Client Rules

<Steps>
  <Step title="Start with one symbol and one route">
    Confirm payload shape, credit cost, and latency before widening a job.
  </Step>

  <Step title="Batch by time range">
    Split long historical pulls into windows that can be retried independently.
  </Step>

  <Step title="Respect 429 responses">
    Honor `Retry-After` when the response includes it. If no retry window is exposed, use capped exponential backoff with jitter, reduce concurrency, and keep `meta.request_id` or `x-request-id` for every failed attempt.
  </Step>

  <Step title="Track cost by route family">
    L3/L4, replay, and deep history routes can behave differently from shallow market-state routes.
  </Step>
</Steps>

## Related Pages

<CardGroup cols={2}>
  <Card title="Limits and throughput guide" icon="gauge" href="/guides/limits-and-throughput">
    Build a client that stays inside rate, concurrency, and credit limits.
  </Card>

  <Card title="Errors and request IDs" icon="file-warning" href="/errors">
    Implement retries, fail-fast handling, and support-ready logging.
  </Card>
</CardGroup>

## Designing Around Limits

Build clients as queues, not as unbounded loops. A historical job should know the venue family, symbol, route, time window, page size, concurrency, and retry budget before it starts. That makes it possible to pause, resume, and explain a run without duplicating data or hammering the API after a rate response.

For `429` responses, stop widening the job until the retry budget has room again. Honor `Retry-After` when present. When it is absent, use capped exponential backoff with jitter, lower worker concurrency, and log the request identifier from `meta.request_id`, `x-request-id`, or the client wrapper. Do not retry unchanged after auth, access, malformed-request, unsupported-symbol, or invalid-parameter errors; fix the request or key first.

Use small probes before wide jobs. One BTC order-book request confirms auth and envelope shape. One one-hour trade window confirms pagination and output schema. Only after those pass should a job widen across symbols or longer history. If a route is heavy because it touches L3, L4, replay, or large history, isolate it from lighter status checks so one slow worker does not block the whole pipeline.

Rate limits are also a product-design signal. If users can trigger arbitrary exports, put bounds in your own UI and show progress. If a coding agent writes a script, ask it to include concurrency controls and request-ID logging before running large loops.

## Liquidation Route Budgeting

Raw liquidation event routes are useful when the job needs row-level liquidation records. They are the wrong default for every dashboard refresh, repeated backtest scan, or broad symbol loop that only needs aggregate exposure. For those jobs, start with `/v1/hyperliquid/liquidations/{symbol}/volume?interval=1h` or the matching HIP-3 `/volume` route, then drill into raw events only for the symbols and windows that need audit-level detail.

If a liquidation job returns `429`, pause widening. Log the failed path and request ID, honor `Retry-After` when present, otherwise use capped exponential backoff with jitter, lower concurrency, and retry with a narrower window or the `/volume` route when aggregate buckets answer the workflow.

## High-Volume Job Config

For high-volume jobs, keep these fields beside the worker config: route family, symbol list, time windows, page size, concurrency, credit budget, retry budget, output path, and stop condition. That config makes it explicit whether the job is a REST workload, WebSocket replay, SDK reconstruction, or Data Catalog export, and gives enough context to pause and resume without duplicating data.