Polymarket API Rate Limits: Gamma, CLOB, and Data
The Short Answer
Polymarket publishes a number for every endpoint, and the numbers are more generous than most people assume. CLOB /book, /price and /midpoint each allow 1,500 requests per 10 seconds. Gamma's /markets is the tightest read limit at 300 per 10 seconds. The Data API runs 1,000 per 10 seconds on v1 and 800 on v2. These are IP-based Cloudflare limits, and exceeding one throttles your requests rather than rejecting them. Order and cancel requests are metered separately against per-signer token buckets that scale with your trading volume.
Key Takeaways
- Every figure below is published per endpoint. You can size a workload before writing it rather than probing for a wall.
- Cloudflare limits throttle, meaning they delay and queue, instead of returning an error. Slow is the failure mode, not failed.
- Singular and plural endpoints differ sharply:
/bookallows 1,500 per 10 seconds,/booksallows 500. - Gamma
/marketsat 300 per 10 seconds is the limit most catalog syncs meet first. - Orders and cancels bypass this layer into per-signer buckets, where cancel budgets are double order budgets at every tier.
- These limits are scoped to an IP address, so separate processes on one host share one allowance.
How many limiters are there?
Three, and they are genuinely independent. Confusing them is the usual reason a fix does not work.
| Layer | Covers | Scoped by | Behavior when exceeded |
|---|---|---|---|
| Cloudflare IP limits | All REST endpoints | IP and endpoint | Throttled, delayed and queued |
| Per-signer token buckets | CLOB orders and cancels | Signer address | 429 with Retry-After |
| Builder Program tiers | Relayer transactions | Builder profile | Rate-limited error |
The rest of this page covers the first layer in detail, since that is the one a read-heavy integration lives inside, and then summarizes the second.
What are the Gamma API rate limits?
Base URL https://gamma-api.polymarket.com. Gamma is the discovery layer, and its per-endpoint limits are the tightest of the three surfaces.
| Endpoint | Limit |
|---|---|
| General | 4,000 req / 10s |
/markets | 300 req / 10s |
/events | 500 req / 10s |
/markets + /events listing | 900 req / 10s |
/public-search | 350 req / 10s |
/comments | 200 req / 10s |
/tags | 200 req / 10s |
That /markets figure is the one to design around. At 300 per 10 seconds you have 30 calls a second for catalog work, which sounds generous until a paginated sync across thousands of markets runs on every loop iteration. Cache the catalog and refresh it on a schedule rather than on demand.
What are the CLOB API rate limits?
Base URL https://clob.polymarket.com. Market data reads here are far more generous than Gamma.
| Endpoint | Limit |
|---|---|
| General | 9,000 req / 10s |
/book, /price, /midpoint | 1,500 req / 10s each |
/books, /prices, /midpoints | 500 req / 10s each |
/prices-history | 1,000 req / 10s |
| Market tick size | 200 req / 10s |
/trades, /orders, /order, /notifications | 900 req / 10s |
/data/orders, /data/trades | 500 req / 10s each |
GET balance allowance | 200 req / 10s |
UPDATE balance allowance | 50 req / 10s |
| API key endpoints | 100 req / 10s |
The singular and plural split is the detail that catches people. /book gets 1,500 per 10 seconds and /books gets 500, so batching is not automatically the cheaper path: three individual /book calls and one /books call draw on different allowances entirely. Which is better depends on how many outcomes you are reading and how often.
Trading endpoints carry both a burst limit and a sustained limit at this layer, before the per-signer buckets are even consulted:
| Endpoint | Burst | Sustained |
|---|---|---|
POST /order, DELETE /order | 5,000 req / 10s | 120,000 req / 10 min |
POST /orders | 2,000 req / 10s | 21,000 req / 10 min |
DELETE /orders | 2,000 req / 10s | 15,000 req / 10 min |
DELETE /cancel-market-orders | 1,500 req / 10s | 21,000 req / 10 min |
DELETE /cancel-all | 250 req / 10s | 6,000 req / 10 min |
What are the Data API rate limits?
Base URL https://data-api.polymarket.com, split across two versions with different budgets.
| Endpoint | Limit |
|---|---|
| v1 general | 1,000 req / 10s |
v1 /trades | 200 req / 10s |
v1 /positions, /closed-positions | 150 req / 10s each |
| v2 general | 800 req / 10s |
v2 /trades | 300 req / 10s |
v2 /positions, /activity, /prices-history | 200 req / 10s each |
v2 /status | 100 req / 10s |
Position reads at 150 per 10 seconds on v1 are the tightest thing here, which matters for a portfolio tracker polling many wallets. v2 raises that to 200 and raises /trades from 200 to 300, so there is a real argument for v2 beyond the schema.
What happens when you go over?
At the Cloudflare layer, requests are throttled rather than rejected: they are delayed and queued, and the limits reset on sliding windows rather than fixed ones. The practical symptom is latency climbing, not errors appearing, which is why this layer often goes unnoticed until a latency-sensitive path starts missing.
The per-signer trading buckets behave differently and do return 429 Too Many Requests, with a Retry-After header giving the minimum delay. Those responses also carry Poly-RateLimit-Remaining, Poly-RateLimit-Reset and Poly-RateLimit-Tier, so your position is observable rather than inferred.
Because the Cloudflare layer is scoped to an IP address rather than an account or a key, every process on one host shares one allowance. Two workers polling the same endpoint from the same machine are drawing on one budget, which is a common surprise when a scanner is scaled out by adding processes.
What about order and cancel limits?
Those run on a separate per-signer system with eight volume-based tiers, from Standard at 40 order tokens per second up to Elite at 600, with cancel budgets double the order budget throughout. Tiers are assigned automatically from the maker wallet's trailing 30-day volume and refresh every three hours, so there is nothing to apply for.
That system, the Builder Program Relayer limits, and the levers that work when you cannot move a tier are covered separately in how to increase your Polymarket rate limit.
Planning a workload against these numbers
The useful consequence of published figures is that a scanner's cost becomes arithmetic. Twenty markets refreshed every second is 20 calls to /book per second, or 200 per 10 seconds, comfortably inside 1,500. The same twenty markets re-resolved through Gamma /markets on every pass is 200 per 10 seconds against a limit of 300, which is where it gets uncomfortable.
The same discipline applies whichever venue you read. Predictefy meters in credits weighted by what a call does rather than how often you ask, and publishes both the weights and the per-plan request limits:
| Plan | Requests per minute | Included credits | API keys |
|---|---|---|---|
| Free | 60 | 25,000 | 1 |
| Builder | 300 | 500,000 | 3 |
| Pro | 3,000 | 5,000,000 | 10 |
curl -s "https://data.predictefy.com/api/polymarket/fetchMarkets?sort=volume&limit=20" \
-H "Authorization: Bearer pk_live_YOUR_KEY"Metadata, search and a price snapshot cost 1 credit; trades or candles cost 2; an order book snapshot or a historical query costs 5; cross-venue comparison costs 10. The limiter uses a fixed 60-second window per API key rather than per IP, so two keys each carry the full allowance and scaling out processes does not divide one budget. Polymarket is one of 16 venues on the same schema.
Frequently Asked Questions
What is the Polymarket API rate limit?
It varies by endpoint rather than being a single figure. CLOB /book, /price and /midpoint allow 1,500 requests per 10 seconds each, Gamma /markets allows 300, and the overall ceiling is 15,000 per 10 seconds. Order and cancel requests use separate per-signer token buckets instead.
Do Gamma, CLOB and the Data API share one limit?
No. Each surface has its own general allowance and its own per-endpoint figures: 4,000 requests per 10 seconds on Gamma, 9,000 on the CLOB, 1,000 on Data API v1 and 800 on v2. Heavy use of one does not directly consume another's budget.
What happens when you exceed a Polymarket rate limit?
At the Cloudflare layer requests are throttled, meaning delayed and queued, rather than rejected, so the symptom is rising latency instead of errors. The per-signer trading buckets do return 429 with a Retry-After header giving the minimum delay before retrying.
Are Polymarket rate limits per account or per IP?
The Cloudflare limits are IP-based, so every process on one host shares a single allowance regardless of how many API keys are involved. The separate CLOB order and cancel buckets are scoped to the signer address associated with your API credentials instead.
Is a batch call cheaper than individual calls?
Not necessarily, because they draw on different allowances. /book permits 1,500 requests per 10 seconds while /books permits 500, so whether batching helps depends on how many outcomes you need and how often. Compare both against your actual read pattern.