Working With Polymarket's Public Market Data
What public endpoints expose about markets, books and history, plus the on-chain data underneath, and how to use both without fooling yourself.

There are two sources of data here and they answer different questions. The venue's public endpoints tell you about markets and the order book. The chain tells you about settled reality. Good pipelines use both and never confuse them.
This page covers public, read-only data. It does not involve a wallet, and this site has no authenticated functionality: it never asks for keys, seed phrases or credentials of any kind, and no price-viewing tool has any reason to.
What the venue's public data gives you
Markets. Question text, resolution criteria, outcomes, close time, status. The criteria field is the one worth storing in full; it is the actual contract and it is what you need when you later ask why two venues resolved differently.
Order books. Resting size by price level on each side. Enough to compute a size-weighted mid and to estimate slippage properly.
Prices and history. Last trade, mid, and time series at various resolutions.
Volume and liquidity measures. Necessary for filtering. Most markets are not tradeable in any meaningful size and you need to exclude them before doing anything else.
What the chain gives you
Settled outcomes, collateral movements, and a permanent record of resolution. If you are building calibration statistics, the chain is the authoritative source for what actually happened, and it does not depend on any API remaining available.

The three disciplines
Timestamp honestly. Store the time the venue reported a value, not the time you fetched it. Every cross-venue comparison is only as good as its older observation, and if you cannot tell how old an observation is you cannot filter on it. Detecting stale data.
Filter before you compare. A market with no offers, or with a book of thirty contracts, produces numbers that look like prices and are not. Most striking cross-venue findings dissolve the moment a liquidity filter is applied, which is the point of applying one. Gap size versus liquidity.
Normalise deliberately. Two venues express the same idea differently: different outcome naming, different threshold conventions, different treatment of ties. Write the normalisation down as code with tests, not as assumptions in your head. Normalising across venues.
Polling politely
Pull the market list occasionally; it changes slowly. Pull books frequently only for the markets you actually care about. Back off on errors. Cache what does not move. Identify your client.
The alternative — polling everything as fast as possible — produces mostly duplicate data, costs you rate limit headroom you will want later, and is rude. Rate limits and polling.
What to build first
A recorder, not a strategy. Capture a small, liquid set of markets on both venues at a sensible cadence, with honest timestamps, for a month. Then look at what you have.
Almost everyone who skips this step builds a backtest on last-trade prices, finds an enormous edge, and discovers that the edge was made entirely of stale quotes and untradeable size. Backtesting honestly is about not being that person.
Next
Multi-outcome markets — the structure that trips up most comparison code.
Educational content only. Nothing here is financial advice, a solicitation, or an offer to trade. Prediction markets can move against you and a position can lose its entire value. Where this guide describes a difference between venues it describes a theoretical cross-market edge in observed prices, which is not a profit: fees, spreads, capital lockup, transfer time and differing settlement rules all come out of it first.



