Capacity planning (verify live terms)
Use the live pricing page for current prices, billing-period switches, and account-specific terms. The table below is a capacity-planning reference, not a live pricing or route-entitlement guarantee; verify current terms, endpoint access, and account/key requirements before relying on it. For starter/free fit checks, use Free tier. A new account’s starting tier and card requirements are account/product terms; verify them in the dashboard. Upgrade only when the live account terms show the needed capacity.
Archive coverage is plan-scoped and separate from request span and throughput. Free serves the most recent rolling 30 days with a maximum 30-day span per request or replay; Build and above keep the full retained archive, subject to credits and physical per-symbol or per-schema availability. Request and replay spans are bounded separately from route access; verify the selected route and current account terms before designing a job.
Webhook delivery is a plan capability rather than a data route: it starts on Build, and the allowance covers endpoints, rules, watched wallets and deliveries a day. Free keeps the two preview surfaces, so a rule can be built and sized with the estimate and the dry-run before there is anywhere to deliver it, and Enterprise allowances are agreed per account. Deliveries do not consume API credits. See Webhooks.
Route-family and schema availability are endpoint-specific questions, not conclusions from a tier name. Verify the exact route, symbol, window, and account/key contract before relying on it. Higher tiers may raise credits, request rate, concurrency, WebSocket subscription caps, standard replay speed, or export credits; Enterprise terms are account-specific.
Data Catalog Export Pricing
Use the Data Catalog when the job is a file purchase instead of a recurring API workload.
Subscriber credits apply before card charge. Every export order has a
$10 job minimum. Volume discounts apply to the amount left after credits: 10% from $250, and 20% from $2,500.
How Limits Work
Client Rules
1
Start with one symbol and one route
Confirm payload shape, credit cost, and latency before widening a job.
2
Batch by time range
Split long historical pulls into windows that can be retried independently.
3
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.4
Track cost by route family
L3/L4, replay, and deep history routes can behave differently from shallow market-state routes.
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.