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.
Archive coverage is separate from request span and throughput. Free can reach older retained history through repeated bounded requests, subject to credits and physical per-symbol or per-schema availability. The Free request or replay span is at most 90 days. Paid plans use
Full current archive; their capacity differs by credits, request rate, concurrency, WebSocket subscriptions, replay speed, and export credits.
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 negotiated benchmark, index, financial-product, redistribution, white-label, or OEM terms when needed.
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. Volume discounts start at
$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.