The fields that are not on a plain ladder
The Hyperliquid L2 order book API is the resting Hyperliquid perp book. The live board is https://cryptodataapi.com/quant-order-books. Start there. Then call the API.
I am Sam Deering. I built this so an agent can read the book. Agents read. They do not trade. We are not a broker.
A plain L2 ladder is two lists. Bids. Asks. Price and size.
This board adds fields a size ladder does not give you.
Each ladder level carries price, size, and count — the number of separate resting orders at that price. One large order can vanish from the book in a single pull. Many small orders at the same price rarely vanish together. The call is GET /api/v1/hyperliquid/l2-book, and every bid/ask entry carries all three fields.
The banded call does not make you sum the ladder by hand. GET /api/v1/liquidity/depth returns USD depth at fixed distances from mid for the tracked universe. Distance from mid, in dollars. Not coin size.
spread_bps is the gap between best bid and best ask, in basis points. It is a cost. It is not a lean.
Each depth record also carries imbalance_10bps — book skew within 10 bps of mid — and total_depth_25bps_usd, the summed bid+ask depth within 25 bps. Those are two different reads: one is a ratio, one is a dollar total.
open_interest_usd is joined onto the same depth record, per coin.
Two calls, two jobs
Send X-API-Key on every call. Machine-readable docs are at https://cryptodataapi.com/llms.txt.
The ladder is one coin at a time:
curl "https://cryptodataapi.com/api/v1/hyperliquid/l2-book?coin=BTC" \
-H "X-API-Key: cdk_live_your_key" \
-H "User-Agent: cryptodataapi-python/1.0"The response is {coin, bids, asks, ts}. coin defaults to BTC if you omit it. Each entry in bids and asks is {price, size, count} — count comes straight from Hyperliquid's own order-count field per level. ts is Hyperliquid's own snapshot timestamp in ms, not our fetch time; it is null only on a pre-deploy cache row. The collector dedupes identical requests for 3 seconds, so two calls inside that window return the same ts.
The banded call is the tradeable summary across the tracked universe:
curl "https://cryptodataapi.com/api/v1/liquidity/depth" \
-H "X-API-Key: cdk_live_your_key" \
-H "User-Agent: cryptodataapi-python/1.0"The response is {as_of, universe_size, coins}. Each entry in coins is one coin's snapshot: coin, ts, mid_price, spread_bps, bid_levels, ask_levels, depth_usd (bid and ask USD depth keyed by band — 10/25/50/100 bps from mid), total_depth_25bps_usd, imbalance_10bps, and open_interest_usd. bid_levels/ask_levels are per-coin fields, not top-level — only as_of and universe_size sit beside coins at the top.
A coin can also come back as a lite record: if Hyperliquid rate-limits us on that coin's L2 book, we keep it in the snapshot with mid_price and open_interest_usd only — spread_bps and depth_usd read null on that record. A null band is a throttled coin, not a missing field on our side.
Recent history is GET /api/v1/liquidity/depth/{coin}?minutes=60. minutes is trailing wall-clock time, default 60, min 1, max 1440 (24h). The response is {coin, minutes, count, history} — count is how many snapshots actually landed in that window, not the minute count itself.
Use the ladder when you need the levels. Use the bands when you need a comparable USD number across coins.
What the board showed on 9 Sep 2026
The board was fetched at https://cryptodataapi.com/quant-order-books on 9 Sep 2026 (AEST). The page marks itself a free launch preview, about 30 minutes delayed. The API is real-time. Use the page for field names; use the API for the current ladder.
The page showed the top 6 perps by 24h volume on that fetch:
| Coin | Mid | Spread | Imbalance | Depth ±10 | Depth ±25 | Depth ±100 |
|---|---|---|---|---|---|---|
| BTC | $78,901.50 | 0.13 bps | 41% ask-heavy | $8.61M | $8.61M | $8.61M |
| ETH | $2,491.05 | 0.4 bps | 6% bid-heavy | $13.46M | $13.46M | $13.46M |
| HYPE | $85.6765 | 0.12 bps | 43% ask-heavy | $0.23M | $0.23M | $0.23M |
| ZEC | $1,235.95 | 0.81 bps | 41% bid-heavy | $0.69M | $2.26M | $2.26M |
| SOL | $103.47 | 0.97 bps | 1% bid-heavy | $4.00M | $8.65M | $8.65M |
| VVV | $25.6575 | 1.17 bps | 18% ask-heavy | $0.04M | $0.05M | $0.05M |
These rows are a read. They are not an order.
HYPE's spread was tighter than BTC's, and the book was still thin — a tight spread is not a deep book. ZEC is where the bands split: depth within ±10 bps was $0.69M, but depth within ±25 bps jumped to $2.26M. BTC, ETH, and HYPE printed the same dollar figure at ±10, ±25, and ±100 on this snapshot — their book depth was already exhausted inside the tightest band, a case the API's levels_truncated flag exists to catch (it marks a band as a floor, not the true depth, when the returned book ran out of levels before the band did).
Leans differed across the six: BTC and HYPE were ask-heavy, ZEC was bid-heavy, SOL was almost flat. A delayed preview number is not the API. If you cite a dollar depth, say whether it came from the preview or from as_of on the live call.
Free is BTC. Pro opens the book
The pricing page lists "BTC Hyperliquid Order book L2" on the free tier. The /liquidity/depth endpoint's own docs say it plainly: the free tier is scoped to BTC; full-universe coverage is Pro and Pro Plus. The tracked universe on that call is the top 25 Hyperliquid perps by 24h volume.
MCP get_order_book proxies straight to GET /api/v1/hyperliquid/l2-book with whatever coin you pass — the product policy, per the pricing page, is BTC on Free and the full coin universe on Pro. A free key should treat non-BTC coins on that path the same way it treats any other Pro surface: read the 403 body if you get one, don't assume the ladder is unlocked for every coin just because the call accepts the parameter.
/liquidity/oi-divergence follows the identical BTC-free / full-Pro pattern as /liquidity/depth.
The board is a preview, not the API scope. It showed six live books and said the rest of the tracked universe is on Pro. A locked card on the preview is a paywall on the HTML page, not a missing endpoint.
Paid Pro on the pricing page is $39 a month, or $29 a month billed annually ($348/yr). Rate limit is 30 requests a minute and 10,000 a day. Pro Plus is $129 a month, or $99 a month billed annually ($1,188/yr), at 120 a minute and 50,000 a day. Free is 10 a minute — 100 a day until the email is confirmed, then 1,000 a day. Confirming also switches Pro on for the same key for 24 hours.
What a 403 is
A JSON 403 on an /api/* path is a tier gate. It carries required_tier and pricing_url. Read it. Do not retry it. Do not mint a second key.
Python's default urllib User-Agent is refused by Cloudflare before the API ever sees the call — error 1010, an HTML 403, not a tier gate. Set a named User-Agent:
curl "https://cryptodataapi.com/api/v1/hyperliquid/l2-book?coin=BTC" \
-H "X-API-Key: cdk_live_your_key" \
-H "User-Agent: cryptodataapi-python/1.0"A missing or invalid key is a 401, not a 403. A 429 is a rate limit; it carries Retry-After.
MCP: get_order_book
The MCP server is at https://cryptodataapi.com/mcp. It lists 26 read-only tools. get_order_book(coin="BTC") is the ladder tool — it calls the same /api/v1/hyperliquid/l2-book path underneath.
list_capabilities and create_free_api_key need no key. The key is shown once; save it, then reconnect.
Call get_order_book for the ladder. If you need the banded USD depth instead, call GET /api/v1/liquidity/depth directly — there is no dedicated MCP tool for the banded read. query_api is the escape hatch for a GET with no dedicated tool. Backtesting routes are not MCP tools by design.
History is captured ladders, not a fill tape
hl_l2_books is captured L2 ladders per perp, archived on a snapshot cadence; liquidity_depth is the banded-depth equivalent. Both are Pro Plus via the backtesting surface. For the authoritative coverage window — exactly which dates exist and how many rows — call GET /api/v1/backtesting/snapshots/types rather than trusting a remembered date; coverage grows forward and the exact start is easy to get stale in prose.
GET /api/v1/liquidity/regime is a different call: a derived per-coin label (deep_book, oi_price_divergence, depth_withdrawal, post_cascade_impaired, neutral) plus a market-wide composite score, gated Pro and Pro Plus — not Pro Plus only. (llms-full.txt currently reads "Pro Plus only" for this endpoint and its /score companion; the endpoint code and docs.html both gate it to Pro and Pro Plus. Read the JSON 403 body over any cached doc text if the two ever disagree.) This regime layer is forward-only and not historically backfillable — it depends on intraday L2 deltas that only exist in the live per-minute buffer, with no historical source to reconstruct them from. It archives daily going forward so a backtestable history builds from here.
A captured ladder every few minutes supports a slippage budget or a depth filter. It does not support tick-level fill simulation.
What this is not
This is not the BTCUSDT fill walk. That sibling post is already live: REST API for BTCUSDT Order Book Depth. It walks one ladder — the arithmetic of slippage against a single book. This post is the multi-coin board at /quant-order-books: order count per level, banded USD depth, and imbalance across the tracked universe. I am not rewriting that post here.
This is not dealer gamma — that is https://cryptodataapi.com/quant-gamma. This is not the whale book — that is https://cryptodataapi.com/quant-whales. A large resting order is not a large account; a whale position is not a resting order.
A delayed preview number is not the API. Not financial advice. It is data.
Get a key, then read the board
Get a free key at https://cryptodataapi.com, or POST /api/v1/auth/keys with a real email. Confirm that email — the same key moves from 100 to 1,000 requests a day, and confirming switches Pro on for 24 hours. That is enough to see a non-BTC book once. It is not a paid plan.
MCP setup is at https://cryptodataapi.com/ai-agents; the tool to call is get_order_book. Pricing is at https://cryptodataapi.com/pricing. The live board stays at https://cryptodataapi.com/quant-order-books.
Read the ladder. Read the bands. Leave a JSON 403 as a 403.
