Guides / Orderbook History
BTC Up/Down orderbook history is the record of what the book actually looked like — every price level and its size, on both sides, timestamped — for Bitcoin's Up/Down markets on Kalshi and Polymarket. Last-price series tell you where a market ended up. Orderbook history tells you whether you could have traded there, at what size, and at what cost. Those are different questions, and only the second one is answerable from depth data.
ProbSights indexes BTC Up/Down across all five contract intervals, so the same query shape works whether you are testing a 5-minute scalp or a daily directional view.
| Contract interval | What it means for BTC Up/Down |
|---|---|
5m | Resolves every 5 minutes. Thinnest books; spread is usually the dominant cost. |
15m | Resolves every 15 minutes. Enough depth to test size without moving the book much. |
1h | Hourly resolution. The most consistently quoted interval across both venues. |
4h | Four-hour resolution. Slower drift, fewer independent observations per day. |
24h | Daily resolution. Closest to a directional bet; overnight gaps matter most here. |
These are two different things, and mixing them up is the usual reason a backtest
looks wrong. The contract interval (5m through 24h) is a property of the
market itself — how often that series resolves. The snapshot granularity
is how often ProbSights recorded the book, set with the granularity query
parameter, which accepts 1m or 5m. A 24h contract sampled at
1m gives you roughly 1,440 snapshots across its life; a 5m contract sampled at
5m gives you a handful. Pick the granularity from the resolution your strategy
needs, not from the contract interval.
Both venues are normalized, but they quote differently and the response keeps that
distinction rather than flattening it into a lossy common shape. Polymarket snapshots carry
bids and asks; Kalshi's carry yes_bids and
no_bids, because a Kalshi No bid is the other side of the Yes book.
| Field | Meaning |
|---|---|
market_id | Normalized market identifier, stable across venues |
timestamp | Unix seconds the snapshot was taken |
bids / asks | Polymarket: arrays of { price, size } levels |
yes_bids / no_bids | Kalshi: arrays of { price, size } levels |
best_bid / best_ask | Top of book (Polymarket) |
best_yes_bid / best_yes_ask | Top of book (Kalshi) |
mid | Midpoint between best bid and best ask |
spread | Best ask minus best bid, in cents |
Find the market you want with search (or
/api/v1/search/markets?coin=BTC), then pull its book history:
GET /api/v1/historical/polymarket/orderbook
?market_id=<market_id>
&granularity=1m
&start_time=1737331200
&end_time=1737417600
&limit=1000Swap polymarket for kalshi to read the same window from the
other venue. start_time and end_time are Unix seconds. Responses
come back as { snapshots, pagination }; when
pagination.has_more is true, pass pagination.pagination_key back as
pagination_key to continue. Do not page by bumping timestamps — snapshots can
share a second, and you will silently drop or double-count rows.
Free accounts get 1m and 5m orderbook charts in the historical data tool. BTC Up/Down history across 5m–24h intervals is on the Pro plan; adding Kalshi alongside Polymarket with a 60-day window is Builder.
Data from Kalshi and Polymarket. Search live API docs Pricing