Same Order Book, Five Depth Caps — and One Venue That Quietly Answers 100

How deep can you ask the L2 order book to go? We put the same question to five exchange APIs on 6 November 2026 and got five different answers — and one venue that ignores an out-of-range parameter without a word of warning.

Disclosure: Produced with AI assistance from data pulled directly from official exchange APIs and documentation. No sponsored placements at the time of writing; if that changes, an #ad notice will appear where any affiliate link is used. Nothing here is financial advice — a technical write-up about API behavior.

Why depth caps matter

If you build anything that touches market data, you will call an order book endpoint. Almost every venue exposes one with a size parameter, and most developers assume it works the same way everywhere: ask for N levels, get N levels, get an error if N is too big.

That assumption is wrong in an interesting way. We sent the same request — "give me the BTC order book, N levels deep" — to five venues and recorded both the documented rules and the actual responses. The caps differ by more than ten times, the defaults by one hundred times, and overshoot behavior splits into four failure modes.

The measurements (6 Nov 2026, 02:03–02:06 UTC)

All requests hit the public, no-authentication market data endpoints directly. Counts below are array lengths in the JSON responses.

Binance — GET /api/v3/depth

Binance's official REST spec (rest-api.md in the exchange's own GitHub docs repository) is explicit: Default: 100; Maximum: 5000. If limit > 5000, only 5000 entries will be returned.

Live check on BTCUSDT: limit=9999 returned exactly 5,000 bids and 5,000 asks — the honest truncation the docs promise. Omitting the parameter returned 100 per side, matching the documented default. The response never echoes your parameter: to know what you received, count the array yourself.

Bybit — GET /v5/market/orderbook

Bybit's docs give a range per product line: spot limit is [1, 1000] with Default: 1; linear and inverse contracts share that range but default to 25; options is [1, 25].

Live check on spot BTCUSDT: limit=600 returned 600 levels per side; limit=2000 was trimmed to 1,000 without an error; and — the sneaky one — omitting the parameter returned a single level per side. A one-level book is a legitimate response, not an error: a script that forgot the parameter would compute depth from one bid and one ask without anything failing loudly.

OKX — GET /api/v5/market/books

OKX documents the size parameter sz with Maximum 400, e.g. 400 bids + 400 asks, and the default is 1 level.

Live check on BTC-USDT: sz=400 returned 400 per side; omitting sz returned 1 per side, both as documented. Overshoot is the interesting part: sz=401 and sz=500 both came back with code "51000" / msg "Parameter sz error." — the one venue here that rejects an out-of-range parameter explicitly inside the returned body. HTTP status is still 200: the error lives inside the JSON, so a client that only checks status codes misses it.

Kraken — the double surprise

Surprise one: the endpoint moved. When we ran the first pass of this research in early September 2026, the method was GET /0/public/GetOrderBook. On 6 November that call returns HTTP 404 with {"error":["EGeneral:Unknown method"]}. The book now lives at GET /0/public/Depth — confirmed both by the live response (full asks and bids arrays, now with a timestamp on every level) and by Kraken's current OpenAPI specification, where the getOrderBook operation is defined as get /public/Depth. Old code breaks loudly, which is the good kind of breakage.

Surprise two: the silent fallback. The OpenAPI schema for Depth defines count as an integer with minimum: 1, maximum: 500, default: 100. Live behavior on XBTUSD:

• count=500 → 500 bids, 500 asks (as documented)
• count=501 → 100 bids, 100 asks
• count=1000 → 100 bids, 100 asks
• count=abc (not even a number) → 100 bids, 100 asks
• parameter omitted → 100 bids, 100 asks

An out-of-range value — even a non-numeric one — is neither clamped to 500 nor rejected: it falls back to the default of 100 with an empty error array. Your tool asked for 500 levels, received 20 percent of that, and nothing in the response says so. Of the four failure modes observed, this is the one most likely to poison a dataset for weeks before anyone notices.

Coinbase Exchange — GET /products/BTC-USD/book?level=2

The Coinbase Exchange full level-2 request at 02:03:19 UTC returned 21,951 asks and 17,395 bids in one response — a complete book, not a capped slice. No published depth cap exists for it, so we report this as an observation, not a comparison point: undocumented behavior deserves the same skepticism as documented behavior.

Four ways to fail the same request

1. Honest truncation (Binance): you overshoot, you get the cap, and the docs told you in advance.
2. Silent trim to cap (Bybit): you overshoot, you get the cap, no complaint in the returned data.
3. Explicit rejection (OKX): you overshoot, you get a named error code — but inside a 200 response.
4. Silent fallback to default (Kraken): you overshoot, you get far less than the cap, looking completely normal.

A fifth lesson comes from the renamed method: endpoints get renamed and removed without your code changing a character. A script written in September 2026 was broken by November — loudly here, but only because the failure was a named unknown-method error rather than a generic timeout.

What to do with this

• Count the arrays you receive. Never assume length matches request: none of the venues above, even the well-behaved ones, echoes your parameter.
• Treat the default as a hostile value. One venue defaults to a single level. Assert that received depth meets what your logic requires, and alert when it does not.
• Parse the body, not just the status code. The only venue that rejects an out-of-range size does so with HTTP 200 and an error field in JSON.
• Re-read the specs on a schedule. Caps, defaults and method names are documentation, and documentation changes. The venue frozen in your notes from last quarter may have moved its door.

None of this makes one venue better than another for trading. It does mean "the API" is not one API, and the cheapest way to corrupt a market-data pipeline is to assume consistency that was never promised.

---

Verify official sources. Every number above was captured live from the venues' own public endpoints on 6 November 2026 (02:03–02:06 UTC) and can be reproduced: Binance https://api.binance.com/api/v3/depth?symbol=BTCUSDT with rules in https://raw.githubusercontent.com/binance/binance-spot-api-docs/master/rest-api.md; Bybit https://api.bybit.com/v5/market/orderbook?category=spot&symbol=BTCUSDT with docs at https://bybit-exchange.github.io/docs/v5/market/orderbook; OKX https://www.okx.com/api/v5/market/books?instId=BTC-USDT with docs at https://www.okx.com/docs-v5/en/; Kraken https://api.kraken.com/0/public/Depth?pair=XBTUSD with the schema at https://docs.kraken.com/api-reference/market-data/get-order-book; Coinbase Exchange https://api.exchange.coinbase.com/products/BTC-USD/book?level=2.

Transparency notes: written with AI assistance, using only the official sources listed above. Affiliate disclosure (#ad): no affiliate or sponsored links appear in this article. This documents public API behavior only — not investment, trading or platform advice. Exchange specs change; confirm current rules on the official pages before relying on anything here.