Polymarket order book
data, snapshot and delta.
Full-depth snapshots and the incremental updates between them, archived as received at the capture cadence in force that day. Replay them in order and you get the book as the archive recorded it — the ladder a fill met, at the depth it met it — rather than a single mid price someone smoothed for you.
What is in the archive
What the archive ships on the order-book side. What YOUR key reaches — which assets, which intervals, which days — comes back from /v1/meta, so you never have to take a page’s word for your own coverage.- book
- Full-depth order-book snapshots
- price_change
- Order-book deltas with best bid/ask
- best_bid_ask
- Top of book, unthrottled — the same best bid/ask price_change carries, at every update rather than the capture cadence; prices only, no sizes, so depth still needs book or price_change
- last_trade_price
- Trade prints, unthrottled
- tick_size_change
- Tick-size changes
Why this archive and not another
Snapshots and deltas, not snapshots alone
A snapshot establishes the book; the deltas carry it forward between snapshots. An archive of periodic snapshots alone cannot tell you what the ladder looked like between two of them, and that is where the fill you are modelling sits. Book and delta capture runs at a cadence, and that cadence has changed over the archive — so what you replay is what was captured, not a claim about every message the venue ever sent.
Top of book is the exception: it ships as its own stream, unthrottled, one row per update rather than one per capture tick. It carries prices only — no sizes — so It carries prices but no sizes; depth still comes from the book and delta streams. Reading top-of-book as depth is the one mistake that silently invalidates a backtest.
Latency you can measure, not assume
The book, price_change and best_bid_ask streams carry the upstream event time and our receive time as two separate fields, never collapsed into one normalised stamp. If you are modelling latency, that difference is the measurement — and a feed that ships one timestamp has already destroyed it. (The settlement streams carry a third, the upstream server time, because that is where it exists.)
Arrival order kept, including out of order
For a book you are rebuilding, the order frames arrived in IS data. A feed someone has silently re-sorted into a tidy sequence can no longer tell you what your strategy would have seen at that instant — it tells you what a cleanup script decided afterwards. We archive frames as received, out-of-order ones included, and leave the reconciling to you.
Gaps are left as gaps, never interpolated over. Every file carries its byte length and a SHA-256, so you can prove you got the bytes we published. Patching a gap still yields a plausible ladder; it is not an observed one.
How to pull it
One key, and /v1/files with whatever filters you want. Every result carries a sha256 and a download url.# list the order-book files your key can reach (newest day in scope by default) curl -H "Authorization: Bearer $OT_KEY" \ "https://outcometick.com/v1/files?venue=polymarket&dataset=book,price_change&asset=btc" # top of book only, unthrottled curl -H "Authorization: Bearer $OT_KEY" \ "https://outcometick.com/v1/files?venue=polymarket&dataset=best_bid_ask&asset=btc" # download one — the listing hands back each file’s url, and /v1/dl 302s to storage URL=$(curl -s -H "Authorization: Bearer $OT_KEY" \ "https://outcometick.com/v1/files?venue=polymarket&dataset=book&asset=btc" \ | jq -er '.files[0].url') curl -L -H "Authorization: Bearer $OT_KEY" "$URL" -o book.jsonl.gz
None of this needs a key to check first. The public sample archive is one real day in the same directory layout and the same formats as the paid one — point your parser at it, verify the checksums. ot run replays it locally through the engine the queue uses.
Don’t want to buy the data?
Paste a strategy and it runs against this same archive in a sealed sandbox — fills matched against the depth that was really there, priced per market-day scanned.