Polymarket websocket data: live streams vs stored 250ms books

Polymarket exposes CLOB websocket channels — market, book, and price — that push events for markets you subscribe to. They are live-only: there is no endpoint to request yesterday's book deltas.

For anything that needs the historical book — a backtest, a replay, a study of settlement — a stored 250ms archive is the record of what the book actually was.

We took the archive's own snapshots and tried to rebuild them by applying websocket deltas from the same capture. 67.8% of the reconstructed books diverged from the stored snapshot, and 6.4% came back crossed.

The divergence is almost entirely missed events — a quote removed, a level cleared — that a live stream cannot deliver retroactively. A stored snapshot archive does not have that problem: the book is captured whole, four times a second. The methodology is in the replay-accuracy post.

• Full ladders at 250ms — four complete bid/ask snapshots per second, on every plan.
• Resolved markets kept — books stay queryable with the winning outcome after settlement.
• REST, not stream — query any window from 1 day down to 250ms against aligned books, prices, and metrics.
• An open sample — 897,192 snapshots on Zenodo, plus a free BTC CSV/JSON download.

The Polymarket websocket is a live event stream: market, book, and price channels that push events for subscribed markets. It is genuinely free and keyless and it moves roughly 24,000 events per second across the venue, but it is forward-only, with no endpoint that can return yesterday's book deltas.

The replay experiment measures the consequence: rebuilding the archive's own snapshots from captured deltas diverged at 67.8% of 381,093 checkpoints, and 6.4% of the reconstructions came back crossed — bid above ask. The missing pieces are removals: a level cleared, a quote pulled, an event that a stream cannot replay retroactively.

That is why the archive stores whole books at 250ms rather than trusting delta reconstruction: the book is captured complete four times per second, so there is nothing to rebuild and no divergence to audit. A stored frame at a past second is a fact; a reconstructed frame is an estimate with a measured failure rate.

The practical workflow for real-time users is to run live and archive in parallel: let the websocket drive current decisions, and pull the stored frames for any second that later matters. Live reads stay free; the archive is the receipt for everything the stream cannot answer after the fact.

For most users the winning setup is hybrid: the websocket for millisecond awareness and a stored-archive query for anything that will be cited later, with the two reconciled on the UTC second.

The decision rule in one line: if a second will matter next week, store it now, because a stream can tell you today what happened, and only an archive can tell you what the book was at a second that has already passed.

Treat the absence of sequence numbers as the design constraint it is: with roughly 24,000 events per second and no sequencing, a dropped message cannot be detected, so any downstream audit needs the stored snapshot as the reference.

When validation matters, compare the stream against a stored frame for the same second rather than against another stream; two streams can diverge together and still look consistent.

A crossed book in a reconstruction is an alarm, not noise — 6.4% of checkpoints returning bid-above-ask means the replay silently priced an impossibility into the data.

For anything that becomes evidence — a backtest, a settlement study, a published number — pull the stored frame instead of the reconstructed one, because evidence is judged by provenance.

• Order book data
• Order book archive
• Replay accuracy post
• What the API serves
• Real-time data