Plan limits define how fast a client can call 0xArchive and which high-depth routes it can use. Treat the live pricing page and any response headers returned for your account as account-specific signals for your key.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.
Current Public Plans
Use the pricing page for checkout and account-specific terms; use this table while designing clients and queue capacity.| Plan | API capacity | Replay and history | Data Catalog credits | Best fit |
|---|---|---|---|---|
Build, $49 /mo | 80M credits, 50 rps, 10 concurrent queries, 25 WebSocket subscriptions | 50x replay with 1 year of historical lookback | $25/mo | Notebooks, dashboards, backtests, and APIs that need broad market history |
Pro, $199 /mo | 400M credits, 150 rps, 20 concurrent queries, 100 WebSocket subscriptions | 100x replay across the full available archive | $100/mo | Production systems that need order-level depth and heavier daily usage |
| Enterprise | custom credits, custom rate limits, custom concurrency, export volume, and retention planning | 200 WebSocket subscriptions, 1000x replay, scoped SLA and commercial terms | Custom | Dedicated throughput, custom delivery, procurement, and security review |
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 | $16/GB | $25 minimum |
| Trades / Liquidations | $25/GB | $15-$25 minimum |
| L2 / L3 Order Book | $10/GB | $10 minimum |
| Funding / Open Interest | $3/GB | $5 minimum |
$500+.
Operating Model
| Control | What it affects | Client behavior |
|---|---|---|
| Requests per second | Burst rate across REST calls | Use backoff and queueing |
| 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 | Check route docs before production use |
Client Rules
Start with one symbol and one route
Confirm payload shape, credit cost, and latency before widening a job.
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.Related Pages
Limits and throughput guide
Build a client that stays inside rate, concurrency, and credit limits.
Errors and request IDs
Implement retries, fail-fast handling, and support-ready logging.
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. For429 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.