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. Every new account starts on the 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 |
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 |
$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
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.