- Full bid /
ask ladderInput - Price × timeAxes
- ~20 HzSnapshot rate
- BTC /
ETH / SOL / XRPMarkets
Charts of best bid and ask tell you where the touch is. A heatmap tells you where the weight is, which price levels hold real resting size, and how that wall builds or melts as the market moves. Because each snapshot carries the full ladder, you can render that picture directly.
A depth heatmap puts price on one axis and time on the other, shading each cell by the resting size at that level. Bright bands are liquidity walls; fading bands are liquidity being pulled. It is the clearest way to see support and resistance form on a prediction market.
What the picture reveals
Liquidity walls
Persistent bright bands mark price levels where size keeps resting, the book’s self-declared support and resistance.
- Resting-size clusters
- Support / resistance
- Where price tends to pause
Liquidity pulls
A wall that fades just before a move is makers stepping back, often the precursor to a fast repricing.
- Vanishing depth
- Pre-move warning
- Thinning into events
Imbalance over time
Brighter bids than asks (or vice versa) across the map shows persistent directional pressure, not a single tick.
- Bid vs ask weight
- Sustained pressure
- Regime, not noise
Building it from snapshots
Request the snapshots with the full book over your window, bucket the price levels into a fixed grid, and aggregate resting size per bucket per time slice. The high capture rate matters here, at roughly 20 Hz on BTC, the heatmap is smooth enough to see walls form and dissolve rather than jump between sparse frames.
- 1Pull the snapshots for the market and window with the book included, set include_book so each row carries its bids and asks arrays, not just the touch.
- 2Bucket prices into a fixed grid (these are 0-1 probability units, so a uniform tick grid is natural) and sum resting size into each price bucket.
- 3Slice time into even columns and aggregate within each slice, so capture jitter doesn’t leave gaps in the picture.
- 4Shade each cell by size, and decide whether to clip or log-scale the brightest cells so one giant wall doesn’t wash out everything around it.
The fields the picture is built from
- bids[] ·
asks[]Full ladder when include_book is set bid_depth_totalResting size on the bid sideask_depth_totalResting size on the ask side- limit ≤ 5000Snapshots per request, paginate long windows
The depth totals give you a fast one-row-per-snapshot summary if you only want the imbalance band; the full bids and asks arrays are what you bucket when you want the whole ladder shaded. Most heatmap pipelines pull the arrays once, then derive everything else from them.
Reading it without fooling yourself
- A bright band is resting size, not executed volume, it shows intent to trade at that level, which can be pulled before anyone hits it.
- Spoofy walls fade the instant price approaches; persistence across many slices is what separates a real level from a placed-and-pulled one.
- Choose your colour scale deliberately, a linear scale buries small structure under one large wall, a log scale surfaces it.
- Sparse categories sample slower (sports near ~2 Hz), so widen the time slices there or the map turns blocky and misleading.
Top-of-book can’t draw this
A heatmap needs the whole ladder, not just the best bid and ask. Polymarket exposes the live book but not its history; the full-depth snapshots are what let you reconstruct the picture for any past window, not just right now.
Best bid and ask tell you where the touch is. The heatmap tells you where the weight is, and weight, not the touch, is what price has to push through.
Get the depth data
The historical guide shows how to request the full book per snapshot; the crypto data page shows coverage.
Frequently asked questions
What data do I need to build an order book heatmap?
You need the full bid and ask ladder over time, not just top-of-book. Request snapshots with the book included over your window; each snapshot’s bids and asks arrays give you the resting size at every price level, which is exactly what a heatmap shades.
Why does snapshot frequency matter for a heatmap?
Higher frequency makes the picture smooth. At roughly 20 Hz on BTC markets, you can watch liquidity walls build and dissolve continuously, rather than guessing what happened between sparse samples.
Can I build heatmaps for ETH, SOL, and XRP too?
Yes. The same full-depth snapshots are captured for BTC, ETH, SOL, and XRP across every timeframe, so the heatmap workflow is identical, only the market id changes.
Does a bright band on the heatmap mean trades happened there?
No, a band shades resting size, the orders waiting at that price, not executed volume. It shows where liquidity is sitting and intends to trade, which can be pulled before price ever reaches it. Persistence across many time slices is what separates a genuine level from a wall that was placed and then yanked.