Polymarket real-time data: free live APIs, and a 250ms history you have to capture

For anything happening now, Polymarket's official APIs are the right answer and they cost nothing: Gamma for markets and resolution, CLOB prices-history with a 1-minute floor, the current book via /book, and a websocket for live book snapshots and price_change deltas.

Real-time and history are different products. The book endpoint and the websocket have no historical counterpart — depth is forward-only. If you need the book as it stood last week, only an archive can answer. Ours stores full L2 ladders every 250ms, queryable from 1 day down to 250ms on every plan.

The websocket carries roughly 24,000 events per second across all markets with no sequence numbers, so a dropped message cannot be detected after the fact. Replaying a public delta archive against its own snapshots diverged at 67.8% of 381,093 checkpoints, with 6.4% returning crossed books and extra levels outnumbering missing ones 4.2 to 1 — removal events absent from the stream.

A live collector gets around this by periodically re-reading the full book; a replay has nothing to re-read against. That is the difference between stored snapshots and reconstructed ones: the archive is whole, four times a second.

• Live now — Gamma, CLOB /book and prices, and the websocket, all free and documented in what the API serves.
• 250ms history — books, prices, and metrics share the same timestamp grid on the REST API; free Starter with 3 days of history, paid windows from 30 to 120 days.
• Same fidelity on sports — full L2 ladders with 35–36 price levels per side on soccer, tennis, NFL, and esports (sports data).
• AI agents — the MCP server reads the archive from Cursor or Claude.

Live data on Polymarket is genuinely free and keyless: Gamma for markets, outcomes, volume, and liquidity; CLOB prices-history with a 1-minute floor; the current order book via /book; and a websocket pushing roughly 24,000 events per second. For anything happening now, the official stack is the right answer and it costs nothing.

The boundary is history. The book endpoint and the websocket are forward-only — there is no official way to ask what the book was at 14:42:50 yesterday. That gap is precisely what a stored 250ms archive fills, and it is why every page on this site pairs "live" with "captured".

The failure mode is visible in the replay experiment: rebuilding stored snapshots from captured websocket deltas diverged at 67.8% of 381,093 checkpoints, and 6.4% came back crossed, because removal events do not survive a stream. A stored snapshot inherits none of that risk.

The practical split is clean: run the official endpoints for current state free, and put the archive behind anything that will be re-evaluated later. Free Starter includes 3 days of 250ms history, which is enough to bridge a weekend and learn the queries before any paid window.

When evaluating any "real-time" provider, ask what happens at reconnect: a stream that cannot resynchronize to a whole book for the missed seconds is not a history candidate no matter how low its latency.

The 24,000-events-per-second figure and the absence of sequence numbers are the two facts that settle the architecture debate: on this venue, history is stored or it is not.

Use the 1-minute prices-history floor as a recon tool, not an execution reference: it shows the shape, while the executable side of any actual decision comes from the 250ms stored book.

Keep one stored day of any market you care about as a hedge; the archive is cheap, and a market that disappears from free history tomorrow is exactly the one a backtest will want.

• Websocket data
• Order book data
• What the API serves
• API pricing
• Trading bot