REST API for BTCUSDT Order Book Depth: Ladder, Spread, Slippage

The REST API call for BTCUSDT order book depth

You want a REST API for BTCUSDT order book depth — a plain GET that returns the resting bids and asks. Here it is:

curl -H "X-API-Key: cdk_live_YOUR_KEY" \
  "https://cryptodataapi.com/api/v1/hyperliquid/l2-book?coin=BTC"

{
  "coin": "BTC",
  "bids": [
    { "price": 78416.0, "size": 2.6707,  "count": 12 },
    { "price": 78415.0, "size": 0.16411, "count": 3 },
    { "price": 78414.0, "size": 0.00014, "count": 1 },
    { "price": 78413.0, "size": 1.45636, "count": 1 }
  ],
  "asks": [ ... ]
}

Each level carries three fields: the price, the total size resting there in base units, and count — how many separate orders make up that size. That third field is unusual and useful: one 2.67 BTC order behaves very differently from twelve small ones. A single large resting order can be pulled in an instant; twelve independent ones rarely vanish together.

Note the symbol translation. You searched for BTCUSDT; the parameter is coin=BTC. The ladder above is the Hyperliquid BTC perpetual, which is where most leveraged BTC flow actually executes. Read the next section before assuming that is a substitute for what you wanted.

BTCUSDT vs BTC: which book are you asking for?

BTCUSDT is a Binance spot pair. BTC is a perpetual futures contract. They are different instruments with different books, and for order-book work the distinction is not cosmetic:

We serve the live L2 ladder for perps, not for Binance spot. That is a deliberate scope choice: the perp book is where liquidation cascades, funding pressure and leveraged size interact, and it is the book most systematic strategies are actually filled against.

If your fills happen on Binance spot, use this feed for market-structure context — is liquidity thinning, is the book lopsided — and take your executable quote from your execution venue. Depth on the dominant perp leads spot conditions far more often than the reverse.

The better call: normalized depth in USD

A raw ladder makes you do arithmetic. Most of the time what you actually want is the answer that arithmetic produces — how many dollars are resting within X of mid — and there is an endpoint that pre-computes it:

curl -H "X-API-Key: cdk_live_YOUR_KEY" \
  "https://cryptodataapi.com/api/v1/liquidity/depth"

{
  "as_of": 1787745082,
  "universe_size": 25,
  "coins": [
    {
      "coin": "BTC",
      "mid_price": 78450.5,
      "spread_bps": 0.127,
      "bid_levels": 20,
      "ask_levels": 20,
      "depth_usd": {
        "bid": { "10bps": 3572955.38, "25bps": 3572955.38,
                 "50bps": 3572955.38, "100bps": 3572955.38 },
        "ask": { "10bps": 3350254.64, "25bps": 3350254.64,
                 "50bps": 3350254.64, "100bps": 3350254.64 }
      },
      "total_depth_25bps_usd": 6923210.02,
      "imbalance_10bps": 0.0322,
      "open_interest_usd": 2780508894.38
    }
  ]
}

Read across that BTC row: a 0.127 bps spread, $6.92M resting within 25 bps of mid, and an imbalance of +0.032 — a bid side 3.2% heavier than the ask side. Open interest is joined in at $2.78B so you can size depth against the leveraged book it has to absorb.

The free tier returns BTC. Pro and Pro Plus return the full 25-coin tracked universe in the same call — useful because ranking coins by total_depth_25bps_usd is how you find the ones that cannot absorb your order.

Turning depth into a slippage estimate

This is what depth is for. Before sending a market order, ask whether the book can absorb it — and walk the ladder if you want the exact answer rather than a band:

import requests

H = {"X-API-Key": "cdk_live_YOUR_KEY"}
BASE = "https://cryptodataapi.com/api/v1"


def estimate_fill(coin, size_base, side="buy"):
    """Walk the live ladder and return the volume-weighted fill price."""
    book = requests.get(f"{BASE}/hyperliquid/l2-book",
                        params={"coin": coin}, headers=H, timeout=10).json()
    levels = book["asks"] if side == "buy" else book["bids"]
    mid = (book["bids"][0]["price"] + book["asks"][0]["price"]) / 2

    remaining, cost = size_base, 0.0
    for lvl in levels:
        take = min(remaining, lvl["size"])
        cost += take * lvl["price"]
        remaining -= take
        if remaining <= 0:
            break

    if remaining > 0:
        return {"filled": False, "unfilled_base": remaining}

    avg = cost / size_base
    return {
        "filled": True,
        "avg_price": avg,
        "mid": mid,
        "slippage_bps": abs(avg - mid) / mid * 10_000,
    }


print(estimate_fill("BTC", 5.0, side="buy"))

Two guardrails worth wiring into any agent that uses this:

• Refuse orders the book cannot fill. If the walk returns filled: False, the ladder ran out before your size did. That is not a slippage problem, it is a sizing error.
• Cap on slippage_bps, not on notional. A $250k order is trivial in BTC and catastrophic in a thin altcoin. The bps number is the one that generalises.

A useful rule of thumb: keep single orders under 10% of total_depth_25bps_usd. Above that you are the market rather than a participant in it.

Spread and imbalance: two numbers, two different jobs

spread_bps and imbalance_10bps look similar and mean completely different things.

• spread_bps is a cost. It is the immediate round-trip penalty for crossing the book. BTC at 0.127 bps is effectively free; ETH quoted 0.406 bps in the same snapshot, roughly 3× wider. A strategy that turns over frequently pays this on every leg.
• imbalance_10bps is a lean. It compares bid depth to ask depth within 10 bps of mid, signed. Positive means more resting bid than ask. It is short-horizon microstructure, not a directional forecast — and it changes minute to minute.

Contrast the two live rows from the same snapshot:

ETH showed 3.2× the depth of BTC at a 3.2× wider spread — deeper but more expensive to cross, and almost perfectly balanced. Those are two genuinely different execution problems, and no price feed would have told you either one.

For how these numbers move rather than where they sit, /api/v1/liquidity/depth/BTC returns recent rolling snapshots of the same record shape. Depth withdrawing ahead of a move is a far better warning than depth being low — a thin book that has always been thin is priced in; a book that just emptied is not.

When to read the book, and when not to bother

Order-book data is expensive to poll and decays in seconds. Reach for it deliberately:

• Before sizing an order — walk the ladder, cap on slippage bps. This is the highest-value use and it is a single call.
• When screening thin markets — rank the universe by total_depth_25bps_usd to find coins your strategy should simply not trade.
• During volatility — market makers pull quotes first and widen second. Depth collapse leads the spread blowout.
• For venue selection — depth joined to open_interest_usd shows which book can absorb a liquidation cascade and which will gap through it.

And where it does not earn its cost: anything with a horizon longer than a few minutes. A book snapshot from an hour ago tells you nothing about the book now. For multi-hour and multi-day work use candles, funding and open interest — those aggregate, and they persist.

Practical cadence: read the book on demand at execution time, and poll /liquidity/depth every minute or two if you are monitoring conditions. Both fit inside the free tier's 10 requests/minute; Pro and Pro Plus raise that to 30/min and 120/min alongside the full-universe scope.