How REST Credits Are Billed
REST API requests are billed by the number of rows a request returns, not a flat fee per call:rows_per_credit depends on the endpoint family:
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
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.