Polymarket Data: Order Books, Prices, History and API
Polymarket data is not one dataset — it is four layers that answer very different questions, and most disappointment comes from using one layer to answer another layer's question. Markets, prices and trades are widely available. The resting order book is the layer that has to be recorded as it happens, and the one that decides whether a fill was ever realistic.
Polymarket data covers four layers: market metadata (what the market is and how it resolves), price history (what it traded at over time), on-chain trades (what executed and by whom), and order-book depth (the resting bids and asks at a moment). The first three are retrievable after the fact; order-book depth exists only if it was captured live.
First-hand figures from the Polymarket archive
These are computed directly from DepthFeed's own capture rather than quoted from a vendor sheet, which is why they carry a measurement date and a named cohort instead of a round marketing number.
Deduplicated recorded books across 380,000+ Polymarket markets.
Observed on the sampled snapshot below; a measured sample, not a service commitment.
Median levels per side on BTC up/down 5-minute markets.
Median total shares resting across both sides of the same cohort.
Measured on the live archive as of June 21, 2026, on BTC up/down 5-minute markets. Coverage grows continuously, so counts are a floor rather than a fixed figure.
Anatomy of a real Polymarket book
This ladder is copied verbatim from one recorded BTC up/down 5-minute observation — it is a real row from the archive, not an illustration.
Yes/Up token book; the No/Down side is the binary complement (down = 1 − up). — captured 10 ms after the exchange timestamp.
- orderbook_up.bids / .asks
- The resting ladder as [price, size] on both sides — what an order actually fills against, and the only field that makes slippage measurable.
- price_up / price_down
- Each outcome quoted 0–1 as an implied probability; Down is the exact complement of Up.
- btc_price
- The underlying reference price, ASOF-joined to this exact snapshot so the book and spot are aligned.
- id / time
- The book's millisecond exchange timestamp; the receive stamp is retained so capture latency stays measurable.
Polymarket coverage at a glance
- Order-book snapshots
- 450 million+ recorded observations
- Markets captured
- 380,000+
- History from
- January 2026 on the longest-running series
- Market windows
- 5-minute, 15-minute, 1-hour, 4-hour, and 24-hour
- Crypto assets
- 7 (BTC, ETH, SOL, XRP, DOGE, BNB, HYPE)
- Settled markets referenced
- 60,307 with recorded outcomes
- Capture method
- Event-driven from the CLOB websocket — not clock-sampled
- Delivery
- REST, CSV and Parquet
Pull Polymarket data by layer
Discover first so identifiers and metadata stay attached to the request, then request recorded observations for one market. include_orderbook returns the stored ladder rather than a flattened price.
curl -s "https://api.depthfeed.com/v3/btc/markets?limit=5" \
-H "Authorization: Bearer df_your_key"
curl -s "https://api.depthfeed.com/v3/btc/markets/<market_id>/snapshots?include_orderbook=true&interval=1m" \
-H "Authorization: Bearer df_your_key"- Omit interval for raw stored resolution; downsampling selects a recorded observation and never interpolates a missing book.
- Follow the response cursor for the next page instead of constructing offset pagination.
- Bind research to the outcome token ID — slugs are for display and are not stable join keys.
The four layers of Polymarket data
Markets and metadata — what the contract actually is
The metadata layer defines the question being traded: the condition and token identifiers, the outcome labels, the market window, the resolution source and the settlement rule. Polymarket's Gamma API is the source of truth here and it is free. This layer is cheap to get and easy to underestimate — most reconciliation bugs downstream are identifier bugs, because a Polymarket market has several identifiers (condition ID, token IDs per outcome, slug) and they are not interchangeable. Bind your research to the token ID for a specific outcome, and keep the slug only for display.
Price history — what it traded at, and at what resolution
The price layer is a time series of where the market traded or was quoted. It answers questions about direction, forecast accuracy and calibration, and for those it is the correct input. Its limitation is resolution and meaning: a last-price series tells you a trade happened at that price, not that your order could have. On short-dated markets a coarse series may carry only a handful of points across a market's entire life, and none of them aligned to the moments a strategy would have acted.
Trades and on-chain flow — what executed, and by whom
Because Polymarket settles on Polygon, executed trades and wallet activity are publicly observable, which is why on-chain indexers cover this layer well. It is the right source for volume, flow, wallet research and leaderboard analysis. What it cannot recover is the book: two very different order books — one with deep size behind the touch, one with almost none — can produce an identical trade tape, so slippage is not derivable from trades alone.
Order books — the layer that must be recorded live
The book is the resting bids and asks at a given instant: the prices, the sizes and how far the ladder goes on each side. It is the only layer that answers whether an order would have filled, at what average price, and what size would have cost. It is also the only layer that cannot be backfilled: once a moment passes, the state of the book at that moment is gone unless something was connected and writing it down. Polymarket streams the live book over its CLOB websocket but serves no archive of it, so historical depth is available only from a party that captured it continuously.
Polymarket data API: matching the request to the layer
DepthFeed serves the recorded layers over one REST surface. Discovery returns markets with their identifiers and metadata; the snapshot route returns recorded observations for a market, with include_orderbook exposing the stored ladder and interval selecting one recorded row per bucket. Downsampling picks a real recorded observation rather than interpolating one, so a gap stays visible as a gap instead of being smoothed into a number nobody measured.
Polymarket dataset downloads: CSV, Parquet or REST
Use CSV for inspection and small flat extracts, Parquet for large columnar research, and REST for bounded or incremental queries. The format should change how bytes are delivered, never what the record means: keep the market identifiers, both the exchange and receive timestamps, the full bid and ask price and size arrays, the settlement fields, and explicit markers where data is absent. A dataset that flattens a ladder to a single price is a price series wearing a dataset's name.
What is deliberately not claimed here
Coverage has a floor and a shape, and both matter more than a headline row count. The archive begins where capture began, not where Polymarket began, and the longest-running series reach furthest back while newer cohorts start later. Latency figures describe measured samples, not a service guarantee. Where a market was not captured, the answer is an explicit gap rather than an interpolated value — which is less flattering and considerably more useful when a backtest depends on it.
Pull a real Polymarket book before you integrate
Start with a bounded recorded sample: check the identifiers, the timestamps and the ladder shape against your own loader, then create a key once the schema fits the job.
More on Polymarket data
Questions, answered.
Much of it is. Polymarket's own Gamma and CLOB APIs serve markets, metadata and price history at no cost, and on-chain indexers cover trades and wallet activity because settlement happens on Polygon. The one layer no free source carries is historical order-book depth, because resting size has to be recorded as it happens and cannot be reconstructed afterwards.