Skip to main content
Credits connect plan economics to actual API and export work: routes, depth, replay, concurrency, and file delivery can carry different cost profiles. Credits are a capacity and planning concept. They help teams size API workloads, Data Catalog exports, and heavier historical jobs before production code starts running broad loops. For current account terms, pricing, and checkout details, use the live pricing page and your dashboard. For client design, use this page with Rate limits.

How REST Credits Are Billed

REST API requests are billed by the number of rows a request returns, not a flat fee per call:
charged = max(1, ceil(rows_returned / rows_per_credit))
Every billable REST request costs at least 1 credit (the floor). rows_per_credit depends on the endpoint family:
Endpoint familyRows per creditApproximate cost
Trades, fills, L2 order book history, funding, open interest, liquidations, Lighter L3 order book1,000about 1 credit per 1,000 rows
Candles10,000about 1 credit per 10,000 rows
L4 (diffs, orders, flow, TP/SL, reconstruction)5,000about 1 credit per 5,000 rows
Single-value (current order book, current funding, current open interest, summary, prices, freshness, instruments, symbols, pairs, outcomes)not metered by rows1 credit
Because billing follows the response size, a narrow time range or a smaller depth returns fewer rows and costs fewer credits. A request that returns no rows still costs the 1 credit minimum. JSON and Apache Arrow output are billed identically. The opt-in ?format=arrow response (available for the trades family) is never cheaper or more expensive than JSON. WebSocket and historical replay billing is unchanged: 1 credit per message. Monthly allowances are unchanged.

Credit Surfaces

SurfaceWhat credits help planDesign implication
REST APIRequest volume, heavy route usage, and historical pullsStart with one route, then batch by symbol and window
WebSocket replayReplay speed, channel count, and historical event volumeBound windows and store replay configuration
Data CatalogFile-style exports and subscriber credit offsetsUse export credits for purchase-style workflows, not infinite API loops
L3/L4 depthLarger payloads and reconstruction-heavy workflowsSeparate high-depth jobs from simple freshness checks
Automation workflowsScripts and agent-assisted jobs that can accidentally widen too fastRequire route, symbol, limit, and concurrency before execution

How To Think About Credits

Credits should make the workflow more explicit. A job should know the route family, symbol set, data family, time window, page size, concurrency, retry budget, and output destination before it starts. If the job cannot state those values, it is not ready to spend broadly. Do not use credits as a substitute for correctness. A job can be under budget and still use the wrong route family. A job can have enough credits and still produce bad research if it ignores freshness or incidents. Treat credits, rate limits, and data quality as separate gates.

Workflow Rules

1

Probe before spend

Run one bounded request, inspect the response envelope, and preserve meta.request_id.
2

Estimate by route family

Separate Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, and Lighter work instead of summing them into one vague market-data job.
3

Split heavy jobs

Batch historical pulls and replay windows so work can pause, resume, and retry without duplicating output.
4

Attach usage context

Store route, window, concurrency, and data-quality decisions with the output so cost can be reviewed later.

API Credits Versus Data Catalog Credits

API credits fit recurring application, research, dashboard, agent, and backtesting workflows. Data Catalog credits fit file-style export purchases. If the user wants to deliver raw data to customers, resell a feed, or package a public dataset, use Data rights and Contact to review the terms instead of treating credits as permission.

Credit Planning Checklist

Before widening a usage-heavy job, capture route family, symbol set, data family, window size, page size, concurrency, retry budget, output destination, and data-quality decision. That checklist separates budget planning from route support and data-rights decisions. Use one checklist for API workloads and a separate checklist for Data Catalog exports. API credits do not make a browser checkout route public, and export credits do not turn file delivery into an unbounded API loop.

Next Step

Use Rate limits for current public plan envelopes and Limits and throughput for queue design.
Last modified on June 28, 2026