Polymarket vs Kalshi Data: What's Actually Available, and How to Use Both
Polymarket and Kalshi look similar from the outside and expose very different data underneath. Here's the honest, per-venue breakdown.
Polymarket is an on-chain CLOB on Polygon with a websocket that streams live order books but no historical order-book archive; Kalshi is a CFTC-regulated US exchange with a clean REST API and a yes/no book up to 100 levels per side, but it does not ship historical order-book depth either. Both give you the live book and neither serves its own depth history — which is the gap third-party capture fills.
Side-by-side
| Polymarket | Kalshi | |
|---|---|---|
| Type | On-chain CLOB (Polygon) | CFTC-regulated US exchange |
| Live market data | CLOB websocket + REST | REST (orderbook, candlesticks, trades) |
| Book shape | Bid/ask per outcome | Yes/no, up to 100 levels per side |
| Historical order book | Not served by the exchange | Not served by the exchange |
| Crypto markets | Up/down, 5m–24h | 15m, hourly, daily, weekly |
| Settlement | Resolution / oracle | Published reference price at expiry |
Polymarket: rich live data, no depth history
Polymarket runs a central limit order book on Polygon. Its CLOB websocket streams live book and price updates, and the REST API exposes markets, trades, and a prices-history endpoint. What it does not provide is a historical archive of order-book snapshots — once a book update passes, the exchange doesn't let you replay it. For backtesting that depends on the resting book, you need a provider that captured the websocket continuously.
Kalshi: regulated, clean REST, still no depth archive
Kalshi is a CFTC-regulated exchange, which shapes its data: a clean REST API with markets, candlesticks, trades, and a current orderbook endpoint, partitioned into live and historical tiers. But the historical tier covers trades and candlesticks, not full order-book depth over time — and the public orderbook endpoint is current-state only. So, as with Polymarket, replaying Kalshi's yes/no book as it was requires continuous third-party capture.
Working with both in one schema
The venues differ in shape — Polymarket's per-outcome bid/ask versus Kalshi's yes/no ladder — so stitching them together yourself means two loaders and two settlement models. DepthFeed normalizes both into one columnar schema: bid/ask price and size arrays, epoch-millis exchange and receive timestamps, and an underlying reference price joined per snapshot, across all seven crypto assets. The same backtest code reads either venue.
Capture differs by venue but the output format does not: Polymarket is captured event-driven from the CLOB websocket (~10 ms median live delivery, measured); Kalshi is polled continuously at full depth (roughly every 1.5 seconds). Both arrive as the identical JSON over the REST API and the live WebSocket stream.
Key takeaways
- 01Polymarket is an on-chain CLOB (Polygon); Kalshi is a CFTC-regulated US exchange.
- 02Both stream or serve the live book; neither serves its own historical order-book depth.
- 03Kalshi books are yes/no up to 100 levels per side; Polymarket books are bid/ask per outcome.
- 04DepthFeed normalizes both into one schema so a single backtest reads either venue.
DepthFeed serves the full Polymarket & Kalshi order book over a REST API and live WebSocket. Free Explorer tier, no card.
Start free