The Polymarket API: What Data You Can Pull and What to Build With It
Every price you see on Polymarket exists in a data feed you can access right now, without permission, without an account, and without paying for it.
Most traders who build tools for prediction markets spend weeks discovering this, usually after starting with screen scraping that breaks every time the UI updates. The Polymarket API is well-documented, actively maintained, and rich enough to support everything from a simple price alert to a full algorithmic execution system. The gap between most traders and this data is not access. It is knowing what the endpoints are and what you can realistically build with them.
Quick Answer
Polymarket exposes two primary APIs: the Gamma API for market data (prices, order books, market metadata, resolution history) and the CLOB API for trade execution (placing orders, managing positions, accessing real-time order book depth). Both are publicly accessible REST and WebSocket APIs with no authentication required for read operations. Historical data goes back to market creation. Rate limits are generous enough for most analytical use cases. The primary constraint for builders is execution latency, not data access.
Key Takeaways
- Polymarket’s data infrastructure has two layers: Gamma API for market information and CLOB API for the order book and execution layer. They serve different purposes and are often used together in the same application.
- All read operations on both APIs are publicly accessible without authentication. You do not need a Polymarket account to pull market data, prices, order books, or resolution history.
- WebSocket feeds provide real-time price updates with sub-second latency on active markets. For execution-speed-sensitive applications, the WebSocket feed is the right data source. For analytics and research, polling the REST endpoints is sufficient.
- Historical data on Polymarket markets goes back to each market’s creation date. For backtesting a model or researching historical price behavior, this data is available from the Gamma API.
- On-chain data on Polygon is the ground truth for all Polymarket positions and settlements. The API data is a processed layer over this. For applications that require absolute certainty about settlement, querying Polygon directly is the authoritative path.
- DG3 is built on top of Polymarket’s data infrastructure. Every fair value calculation, edge ranking, and signal in DG3 ultimately draws from the same API endpoints described here, processed through DG3’s analytical models.
The Two Polymarket APIs
The Gamma API
The Gamma API is Polymarket’s primary market data API. It provides:
Market listing and metadata: market title, description, resolution criteria, creation date, resolution date, category, and status (open, resolved, closed).
Price history: YES and NO prices over time for any market, at various intervals from tick-by-tick to daily.
Current prices and order book snapshots: the current best bid and ask for YES and NO on any market.
Resolution data: final settlement prices and resolution outcomes for historical markets.
Volume and liquidity data: total trading volume, open interest, and liquidity metrics per market.
The Gamma API uses standard REST conventions. Requests are GET-based with query parameters for filtering by market, time range, and data type. The base URL structure follows predictable patterns and the documentation lists full endpoint schemas. For Python users, the py-clob-client library handles the CLOB execution layer, while the Gamma API REST endpoints are callable directly via the requests library.
The CLOB API
CLOB stands for Central Limit Order Book. The CLOB API is the execution layer: it handles order placement, order cancellation, and real-time order book data.
Unlike the Gamma API, write operations on the CLOB API (placing and cancelling orders) require authentication via your Polymarket wallet. Read operations (order book depth, recent trades) are public.
The CLOB API also provides WebSocket endpoints for real-time streaming. Subscribing to a market’s WebSocket feed delivers price updates as they happen, typically with latency measured in milliseconds on active markets. For any application where execution timing matters, the WebSocket feed is the correct data source.
Rate limits on both APIs are generous enough for most analytical applications. High-frequency polling across hundreds of markets simultaneously may require backoff logic, but single-market or small-portfolio monitoring is well within documented limits.

5 Things You Can Build With the Polymarket API

1. A price alert system. The simplest useful application. Poll the Gamma API for YES prices on a watchlist of markets at regular intervals (every 30-60 seconds is reasonable without hitting rate limits). Compare current prices against threshold values and trigger alerts when a market moves beyond a defined percentage or absolute price change. Build time: a few hours in Python with requests and a notification service like Telegram or email.
2. A historical price research tool. Pull full price histories for markets in a specific category (political, sports, macro) and analyse price behavior around specific event types. How much does a presidential election market move in the 24 hours before a major polling release? How fast does a World Cup group stage market correct after a goal? This kind of research requires historical price data at sufficient granularity, which the Gamma API provides going back to market creation.
3. An arbitrage scanner for categorical markets. Pull current YES prices for all outcomes in multi-outcome categorical markets. Sum the YES prices per market. Flag markets where the sum falls below 1.00 as negative risk candidates. Sort by the size of the gap. This is a straightforward data processing task on top of the Gamma API’s market listing and current price endpoints. Build time: a few hours. The harder part is the execution layer, which requires the CLOB API.
4. A backtesting framework for probability models. Build a probability model for a specific market type (Fed rate decisions, electoral outcomes, sports results). Pull historical market prices at model run times and compare model outputs against what the market was pricing at equivalent moments. Calculate hypothetical P&L if you had traded at those prices. This is how systematic traders validate edge before deploying capital. The Gamma API’s historical price data makes this possible without maintaining your own data collection infrastructure.
5. An algorithmic execution system. Use the CLOB API to place limit orders, manage open positions, and execute strategies that respond to real-time market data from the WebSocket feed. This is the most complex use case and the one most likely to encounter the practical limitations of Polymarket automation – partial fills, gas costs for each transaction, and the risk of stale orders in fast-moving markets. The Automating Polymarket Trades guide covers this use case in detail.
What the API Does Not Give You
Three gaps that matter for builders.
Real-time resolution data. Market resolution is confirmed on-chain through UMA Protocol’s oracle. The API reflects resolution status, but there can be a delay between when a resolution is finalized on-chain and when it appears in the Gamma API response. Applications that need instant resolution confirmation should monitor the Polygon blockchain directly.
Full order book history. The Gamma API provides historical price snapshots and current order book depth. It does not provide a full historical record of every order placed, cancelled, and filled. For market microstructure research that requires order-level data, on-chain data from Polygon is the only complete source.
Identity of trading wallets in the API response. The Gamma API aggregates trade data. Individual wallet identities behind each trade are not exposed through the Gamma API. On-chain data provides wallet-level transaction history, but parsing this at scale requires direct Polygon data infrastructure. This is the gap that makes building a whale tracker from scratch significantly more work than it sounds.
Common Mistakes
Mistake 1: Screen scraping Polymarket instead of using the API. The Polymarket front end changes frequently. Screen scrapers break silently when UI elements move. The API is stable, versioned, and designed for programmatic access. If you are pulling data from Polymarket for any repeating task, use the API.
Mistake 2: Polling the REST API for time-sensitive applications. If you are building something that needs to respond to price changes within seconds (execution systems, arbitrage scanners for fast-moving markets), polling REST endpoints at 30-second intervals is too slow. Use the WebSocket feed for real-time data. REST polling is appropriate for analytics and research; WebSocket subscription is appropriate for execution-speed-sensitive applications.
Mistake 3: Assuming API prices are the same as on-chain settlement prices. The Gamma API prices are the mid-market prices from the CLOB order book. They are not settlement prices. Settlement prices are determined by UMA Protocol on-chain at resolution. For most use cases these align closely, but for applications that depend on precise settlement values, verify against on-chain data.
Mistake 4: Ignoring gas costs in execution systems. Every order placed through the CLOB API results in an on-chain transaction on Polygon. Gas costs for each transaction are real and accumulate. An algorithmic system that places 50 orders per day across multiple markets is paying meaningful gas costs that need to be accounted for in any P&L calculation. The Gas-Aware Betting article covers how to model this.
Mistake 5: Building without first reading the resolution criteria. The Gamma API provides resolution criteria as text in the market metadata. Any application that trades, alerts on, or analyses specific markets needs to account for the exact resolution rules. Markets that look similar (two “will X win” questions) can have meaningfully different resolution criteria and timelines. Read the criteria before building any logic that depends on resolution outcome.
How DG3 Fits
DG3 is built on Polymarket’s API infrastructure. The Fair Value Engine, Edge Finder, Signal Layer, and P&L Tracker all draw from the same Gamma and CLOB API endpoints described here, processed through DG3’s analytical models in real time.
For traders who want API-level intelligence without building it themselves, DG3 provides the output of what a well-built Polymarket API application produces: devigged prices, edge rankings, order flow signals, and position-level performance tracking. For developers who want to build their own tools, the Best Polymarket Tools guide shows what the current tool landscape looks like above the API layer.
Frequently Asked Questions
Q: What data does the Polymarket API provide? A: The Polymarket API provides market metadata (title, description, resolution criteria, dates), historical and real-time prices for all outcomes, order book depth, trading volume, liquidity metrics, and resolution outcomes for settled markets. The Gamma API covers market data; the CLOB API covers the order book and execution layer.
Q: What are the main Polymarket API endpoints? A: Key Gamma API endpoints cover market listing (all active markets with metadata), market detail (single market data including price history), and resolution data. Key CLOB API endpoints cover order book depth (best bid and ask for all outcomes), recent trades, WebSocket subscription for real-time updates, and order placement and cancellation (requires wallet authentication for write operations).
Q: How do I get historical Polymarket data? A: The Gamma API provides historical price data going back to each market’s creation date. Use the price history endpoint with a time range parameter to pull data at various intervals. For a specific market, request the market ID from the market listing endpoint and use it to pull the price history. For Python users, calling the Gamma API REST endpoints directly via requests takes a few lines of code.
Q: What can I build with the Polymarket API? A: Price alert systems, historical price research tools, arbitrage scanners for categorical markets, backtesting frameworks for probability models, and algorithmic execution systems. The complexity ranges from a few hours of work (price alerts) to weeks of development (a production-grade execution system with proper error handling and gas management).
Q: How does DG3 use Polymarket’s data infrastructure? A: DG3 pulls market data from the Gamma and CLOB APIs in real time and processes it through its analytical models: the Fair Value Engine deviggs prices, the Edge Finder ranks markets by fair value divergence, and the Signal Layer cross-references market price movements against news and on-chain whale flow. The terminal interface surfaces the outputs of this processing rather than raw API data.
Q: Can I build a trading bot using the Polymarket API? A: Yes. The CLOB API supports programmatic order placement and cancellation with wallet authentication. Building a fully automated trading system requires handling order fills, managing gas costs for on-chain transactions, dealing with partial fills, and implementing proper error handling for network issues. These are solvable engineering problems, but they add significant complexity beyond the basic API access.
Q: What are the Polymarket API rate limits? A: Rate limits are documented in Polymarket’s API documentation and are generous enough for most analytical use cases. Single-market monitoring and small-portfolio research stay well within limits. Applications that poll many markets simultaneously at high frequency may need to implement backoff and request queuing logic. For real-time data, the WebSocket feed avoids polling rate limit concerns.
Q: How do I pull Polymarket data in Python? A: For the CLOB execution layer, install py-clob-client (pip install py-clob-client). For read-only Gamma API access, call the REST endpoints directly using requests – no package required. The Gamma API base URL and endpoint structure are consistent and well-documented.
Final Thoughts
The Polymarket API is one of the more accessible data sources in financial markets. No API key required for read operations. Historical data available. WebSocket feed for real-time updates. Reasonable rate limits.
The gap between most traders and this data is not the API. It is knowing what question to ask of the data once you have it. A price history download is raw material. An edge model built on historical price behaviour relative to outcome frequencies is the thing of value.
Start with the simplest possible application, a price alert for a market you are tracking. From there, the path to more complex tools follows the same API surface, just with more of it in use at once.
The data is there. The question is what you build.
Sign up now – DG3 Terminal
