Polymarket Historical Data: Prices, Trades, Order Books, and API Access

If you are researching Polymarket, the first practical question is usually where to find Polymarket historical data — prices, trades, and order books — and how to download it for analysis. The answer depends on what you are building. Charting how a market repriced last month is a different problem than simulating whether a $2,000 order would have filled against the bid stack.

This guide walks through what Polymarket exposes on its own, what you need an archive for, when price history is enough, when full book depth is required — and a short Python example to pull a time series.

What Polymarket provides directly

Polymarket splits public data across a few surfaces. None of them is a complete historical archive for every research use case, but each covers part of the picture:

• Historical prices — Polymarket exposes historical price-series endpoints, including batch price history. These are useful for probability and time-series analysis, but they are not equivalent to archived L2 order-book snapshots.
• Gamma API — discovery and metadata: events, markets, tags, current outcomes, volume, and liquidity fields useful for browsing. Good for finding what exists and what is active today.
• CLOB API — trading and live market structure: placing and canceling orders, recent trade activity, and the documented order-book endpoint, which returns the current book for a token. Real-time book updates stream over the WebSocket; neither replaces a historical L2 archive.
• On-chain settlement — outcome resolution and token mechanics live on Polygon. That layer confirms final states; it is not a convenient historical prices API.

If you are looking for a Polymarket order book API, the official CLOB API gives you the current book, while a historical archive is needed for past L2 snapshots.

In practice, teams that only call Polymarket directly can answer "what is the market quoting right now?" and "what traded recently?" Polymarket provides historical price-series endpoints, but researchers still need a separate archive if they want to replay full historical L2 bid/ask ladders at arbitrary past timestamps.

Is the Polymarket API free? Rate limits and what you actually get

Developers often ask is Polymarket API free. Polymarket provides public API access to market metadata, historical prices, and live market data. Usage is subject to documented rate limits, and this access is not the same as a historical L2 archive.

Polymarket API rate limits still apply. Polymarket applies IP-based rate limits and throttling across its APIs, so high-volume collectors need to respect the documented limits and design for backoff and pacing. Those constraints are aimed at live apps and market makers, not unattended bulk backfills across thousands of markets.

The documented order-book endpoint returns the current book for a token; the WebSocket streams real-time updates. Neither offers a way to page through archived L2 depth from six months ago. For stored snapshots, you either run your own recorder or query a hosted historical API with /books and /prices routes.

What requires an archive

An archive (your own pipeline or a hosted historical API) stores snapshots over time so you can query the past on demand. You typically need one when:

• You want prices, metrics, and books from one queryable archive — consistent schemas and pagination — without stitching separate Polymarket endpoints or pacing around IP limits.
• You need historical order book data — multiple price levels with size, not just the last print or a single mid.
• You are backtesting across many markets and want consistent schemas, pagination, and API keys instead of ad-hoc CSV dumps.
• You want bulk export for a warehouse (some providers also offer Enterprise S3 drops in Parquet, CSV, or JSON).

Recording everything yourself is possible: websocket feeds, token-id normalization, deduplication, and cold storage add up fast. Most research teams eventually buy time back by querying someone else's store.

Prices, trades, and order books — three different downloads

These terms get used interchangeably in search, but they answer different questions:

• Prices — time series of implied probability (per outcome token), usually derived from the top of book or last trade. Lightweight, ideal for charts, correlation studies, and coarse signal research.
• Trades — discrete prints: size, price, side, timestamp. Answers "what actually exchanged hands?" Useful for volume profiles and trade-based backtests, but incomplete for limit-order strategies that might never have traded.
• Order books (L2) — bid and ask ladders: price and size at each level. Answers "what was available to hit or join?" Required when spread, depth, and queue position matter.

A hosted archive API often exposes all three (or prices + books + derived metrics) over the same start_ts / end_ts window so you can align series in one notebook.

When prices and trades are enough

Start with price history when your question is about direction or level, not execution quality:

• Plotting how a market repriced before an election, macro print, or sports result.
• Comparing implied probabilities across related markets.
• Training models where fills are assumed at mid or at last trade (know the limitation).
• Screening hundreds of markets for volatility or drift without per-market book storage.

Trade history extends that when you care about observed activity — how much size cleared and at which prices — but you are still okay ignoring orders that rested on the book without filling.

When you need order book depth

Move to full L2 ladders — Polymarket order book data with size at each level — when assumptions about liquidity stop being harmless:

• Estimating slippage for sizes larger than the top of book.
• Modeling limit orders that join the bid and may or may not fill.
• Measuring spread and depth over time, not just midpoint.
• Serious backtests where "fill at mid" would overstate edge.

For a deeper walkthrough of that gap — why mids and prints are not enough — see How to Get Historical Polymarket Order Book Data for Backtesting.

Python example: pull historical prices

The script below uses a read-only archive API (no live Polymarket calls on the read path). Set POLYORDERBOOKS_API_KEY from your dashboard after signup.

1. Discover a market with GET /v1/markets (search, status, category filters).
2. Pull GET /v1/markets/{slug}/prices with start_ts, end_ts, and resolution (e.g. 60s on Starter).
3. Parse data keyed by outcome label; each point has t (timestamp) and p (price). Paginate with metadata.next_cursor for longer windows.
4. For book depth on the same window, call /v1/markets/{slug}/books instead — same time parameters, ladders in b / a arrays.

import os
from datetime import datetime, timedelta, timezone

import requests

BASE = "https://api.polyorderbooks.com"
API_KEY = os.environ["POLYORDERBOOKS_API_KEY"]
HEADERS = {"X-API-Key": API_KEY}

# 1. Pick a market
markets = requests.get(
    f"{BASE}/v1/markets",
    params={"search": "bitcoin", "limit": 5, "status": "active"},
    headers=HEADERS,
    timeout=60,
)
markets.raise_for_status()
slug = markets.json()["data"][0]["slug"]

# 2. Pull a day of historical prices
end = datetime.now(timezone.utc)
start = end - timedelta(days=1)

prices = requests.get(
    f"{BASE}/v1/markets/{slug}/prices",
    params={
        "start_ts": start.isoformat().replace("+00:00", "Z"),
        "end_ts": end.isoformat().replace("+00:00", "Z"),
        "resolution": "60s",
        "limit": 500,
    },
    headers=HEADERS,
    timeout=120,
)
prices.raise_for_status()
payload = prices.json()

for outcome, points in payload["data"].items():
    print(outcome, "buckets:", len(points))
    for point in points[:3]:
        print(" ", point["t"], "price", point["p"])

# 3. Need L2 depth? Same window, swap to /books
# books = requests.get(f"{BASE}/v1/markets/{slug}/books", params={...}, headers=HEADERS)

Export to CSV by writing points rows in your loop, or use the official Python SDK on PyPI if you prefer a typed client. Parameter details and response shapes are in the quickstart and historical overview.

Choosing your path

Polymarket historical data spans more than one source. Use Polymarket's own APIs — including documented historical price endpoints — for discovery, trading, and probability time series; use an archive when you need stored order book snapshots, unified exports, or full L2 replay at scale.

A practical workflow: pull prices for the question you have today, validate the signal, then upgrade to /books only if execution realism matters. A free Starter tier is enough to prototype on recent crypto markets — expand resolution or lookback when the research justifies it.

---

Disclosure: I work on PolyOrderbooks, a hosted historical Polymarket data API. This post reflects how we think about the problem space — not affiliated with Polymarket.