What you get per snapshot
Each snapshot is a full L2 book for one token at one point in time:Walk an interval
The simplest replay loop: pull snapshots between two timestamps, then iterate.limit caps at 200 snapshots per call. The walk pattern above advances the cursor to the last snapshot’s timestamp plus one millisecond.
Simulating fills
The honest way to simulate a fill against a historical book:
For resting limit orders, pair orderbook snapshots with the trades endpoint over the same window. The trades tape tells you what actually crossed; the orderbook tells you whether your resting order would have been the resting side.
Slippage and depth checks
You can answer “could I have actually traded $X in this market at the time?” directly from a snapshot:Backtesting tips
- Use both sides of the market. Subscribe (or replay) Yes and No outcomes. Spreads between them often imply arbitrage opportunities or stale liquidity.
- Snapshots aren’t tick-level. They’re produced when the book changes. Between two snapshots, assume the book held — don’t interpolate.
- Watch for empty books. Newly created markets, low-liquidity outcomes, and weekends all produce sparse snapshots. Handle
bids: []andasks: []gracefully. - Pair with the trades endpoint.
GET /v2/polymarket/tradesgives you the actual fills that happened — useful for validating your simulated execution.
Going live with the same logic
Once a strategy backtests well, the live version uses the same shapes via the orderbook WebSocket channel instead of REST. Thebook_snapshot event has the same bids / asks shape, and price_change events let you maintain the book incrementally — so your decision function rarely needs to change between backtest and prod.