Prediction market API rate limits, tested with a daily ramp
Warm latency on book, price and list endpoints of eight prediction market venue APIs, plus a daily rate limit ramp that records added latency and throttle onset per request tier.
TL;DR. As of , Polymarket posts the lowest warm book latency at 96 ms (p50, 24h) across 6 ranked venues. Source: OpenChainBench, https://openchainbench.com/benchmarks/pm-rate-limits.
Read this carefully
Ramp tiers stay well inside documented budgets where they exist, at most 7 percent of Polymarket's published book allowance, and every run aborts at the first sign of sustained errors. This benchmark measures throttle onset behaviour at polite request rates, not maximum venue throughput.
Every prediction market venue documents its API rate limits differently, and some not at all. Polymarket publishes per endpoint budgets but fronts its CLOB with Cloudflare, which queues bursts instead of rejecting them. Kalshi documents a token bucket per access tier. Manifold publishes a per IP budget and explicitly welcomes bots. Limitless documents nothing. Builders sizing a polling loop or a trading bot against these APIs need two numbers nobody publishes: the real latency of the hot endpoints at a polite request rate, and what actually happens as the request rate climbs. This benchmark measures both. A harness in three regions probes the book, price and list endpoints of each venue continuously over warm connections, and once a day per venue it runs a short ramp, 60 seconds per tier at rising request rates, recording added latency versus the same hour baseline and any 429 or 5xx onset. The leaderboard sorts by warm book endpoint p50, the ramp results render as companion panels.
Methodology
Each venue is probed on three endpoint classes: book (the order book of a pinned market, or its closest equivalent), price (a single market quote) and list (the venue's market listing). Probes run every 5 to 7 seconds over a warm keep alive pool, with a separate cold connect probe once a minute that forces a fresh TCP and TLS handshake. Every sample records full round trip, time to first byte and a CDN cache flag taken from the response headers, because some venues serve part of their API from an edge cache and a cached read says nothing about the API origin. The pinned market is re selected daily at 00:00 UTC, most liquid, near the money, expiring more than 24 hours out, and immediately re pinned when a venue starts answering with errors that are really our pin's fault, such as a market that resolved intraday. Those samples are classified probe_invalid and never count against the venue. The daily ramp fires from one region at a time on disjoint UTC hours, 60 seconds per tier at rates that stay well inside documented budgets where they exist, and aborts the moment throttled plus server errors exceed 1 percent of a 10 second window.
- Endpoint classes per venue. Polymarket: CLOB `/book`, `/midpoint`, Gamma `/markets`. Kalshi: `/markets/{ticker}/orderbook`, `/markets/{ticker}`, `/markets`. Limitless: `/markets/{slug}/orderbook`, `/markets/{slug}`, `/markets/active`. Manifold: `/v0/bets`, `/v0/market/{id}`, `/v0/markets`. Myriad, PredictIt, Metaculus: price and list only (no order book). Smarkets: `/v3/markets/{id}/quotes/`, `/v3/markets/{id}/`, `/v3/events/`.
- Pinned market per venue: most liquid, near the money (price between 0.15 and 0.85), expiring more than 24h out. Re pinned daily at 00:00 UTC and immediately on probe_invalid. A degenerate 0.99 book has a latency profile that does not represent real usage.
- Warm probes every 5s (7s on Manifold, whose entire API sits behind max-age=5 plus stale-while-revalidate=10; tighter spacing would only measure the cache). Cold connect probe once per minute with keep alives disabled, TCP plus TLS handshake recorded separately.
- Every sample records a cache flag from cf-cache-status, x-cache and age headers. Kalshi's market list is served from CloudFront with max-age=15, so its list latency measures the edge, not the API. Edge served samples (cache=hit) are excluded from every latency aggregate and reported through the cache label, so no venue ranks on its CDN.
- Outcome classification: ok, timeout (8s), http_4xx, http_5xx, throttled (429), probe_invalid, net_error. Latency aggregates include successful requests only; failures count toward the success rate. probe_invalid covers stale pins, e.g. Limitless serves a CDN cached 400 for four hours once a market expires. Those are our fault, never the venue's.
- Daily ramp: 60s per tier at rising requests per 10s window against the book endpoint, one venue at a time, one region at a time on disjoint UTC hours (02:00 us-east, 04:00 eu-west, 06:00 sgp).
- Ramp tiers: Polymarket + Kalshi 25/50/100 per 10s, Manifold 15/30/60, Limitless 10/20/40, Smarkets 10/25/50, Metaculus 5/10/20. Kalshi stops at first 429 (documented token bucket). Myriad excluded (keyless budget 30/10s). PredictIt excluded (5 req/min published limit).
- Ramp abort guard: the run stops the moment throttled plus 5xx responses exceed 1 percent of any 10 second window. The headline ramp metric is p50 latency during the tier minus the warm baseline p50 of the previous hour in the same region, because venues behind Cloudflare queue bursts without ever returning 429, and added latency is the only honest throttle signal there.
- WebSocket panel covers venues with a public market WebSocket, which today means Polymarket only. Kalshi requires authentication for WS, Manifold and Myriad have none, Limitless uses socket.io. Absence is shown, not penalized.
- Myriad's origin is a single region US East deployment behind Heroku. Latency from eu-west and sgp is geography, reported as measured.
- All probes hit documented public developer APIs with the identifying User-Agent `OpenChainBench/1.0 (+openchainbench.com/methodology; contact@openchainbench.com)`. We publish latency measurements only, never order book contents or prices, in line with venue data redistribution terms (Kalshi's in particular, applied to all venues equally).
- Regions: us-east, eu-west, sgp (Railway). Histogram buckets 25ms to 10s.
Results: 6 venues ranked by Warm book latency (p50, 24h)
| № | Venues | Warm book p50 | p90 | p99 | Ramp added latency | Cold connect | WS connect to snapshot | Success |
|---|---|---|---|---|---|---|---|---|
| 1 | Polymarket | 96 ms | 221 ms | 247 ms | 16 ms | 6 ms | 1.50 s | 100.00% (n=51839) |
| 2 | PredictIt | 104 ms | 188 ms | 3.03 s | — | 8 ms | — | 66.45% (n=17280) |
| 3 | Manifold | 119 ms | 385 ms | 9.48 s | -0 ms | 8 ms | — | 99.98% (n=37029) |
| 4 | Kalshi | 121 ms | 368 ms | 871 ms | 4 ms | 8 ms | 5.0 min | 100.00% (n=51840) |
| 5 | Limitless | 291 ms | 389 ms | 852 ms | 10 ms | 7 ms | — | 100.00% (n=51840) |
| 6 | Myriad | 506 ms | 1.36 s | 1.54 s | — | 200 ms | — | 100.00% (n=51840) |
Frequently asked
What is the Polymarket API rate limit?
Polymarket documents per endpoint budgets for the CLOB API, on the order of 1500 requests per 10 seconds for the book endpoint at the time of writing. In practice the CLOB sits behind Cloudflare, which queues bursts rather than rejecting them: at our daily ramp tiers (up to 100 requests per 10s) we observe added latency instead of 429 responses. The ramp panel above shows the measured added latency per tier, refreshed daily.
What happens if you exceed prediction market API rate limits?
It depends on the venue's architecture. Kalshi runs a documented token bucket and returns 429 when the bucket is empty. Polymarket's Cloudflare front queues requests, so you see rising latency before you ever see an error. Manifold documents 500 requests per minute per IP and asks bots to stay on one IP. Limitless documents nothing. The daily ramp records which of these behaviours each venue actually exhibits at each tier.
What is the Kalshi API rate limit?
Kalshi documents tiered rate limits per access level, with the basic read tier around 20 requests per second at the time of writing. It is the only venue in this cohort with a documented token bucket. Our ramp stops at the first 429 on Kalshi out of respect for that documented contract, and the tier where it happens (or does not) is recorded in the ramp panel.
Which prediction market has the fastest API?
Polymarket currently has the lowest warm book endpoint latency at 96 ms (p50 over the last 24h). Note what this does and does not measure: it is the latency of the venue's own public API over a warm connection at a polite request rate, per region. For data freshness and WebSocket latency, see the pm-api-latency and pm-ws-latency benches.
Does Manifold have an API rate limit?
Yes, 500 requests per minute per IP, documented, and Manifold explicitly welcomes bots as long as they stay on a single IP. Be aware that the whole API is served behind a cache with max-age=5 and stale-while-revalidate=10, so polling faster than every 6 seconds mostly returns cached responses. Our probes space out to 7 seconds per URL and label every sample that still comes back from cache.
What are the Limitless API rate limits?
Limitless does not document rate limits. Our ramp therefore uses the most conservative tiers in the cohort (10/20/40 requests per 10s) with an automatic abort. One measured behaviour worth knowing: error responses are CDN cached for four hours, so a request for an expired market keeps returning the same cached 400 long after the market resolved. A client that does not handle this will misread the API's state for hours.
How do you test rate limits without abusing the APIs?
Four guardrails. Tiers stay well inside documented budgets where they exist (at most 7 percent of Polymarket's book allowance). Every run aborts as soon as throttled plus server errors exceed 1 percent of a 10 second window, and Kalshi stops at the first 429. Only one region ramps a venue at a time, on disjoint UTC hours. And every request carries an identifying User-Agent with a contact address, so a venue can reach us or filter us selectively. The measurement is throttle onset, not stress to failure.
Why measure the venue APIs directly instead of a data provider?
They answer different questions. If you build directly on a venue, its native API latency and throttle behaviour set your floor, and that is what this benchmark measures. For API latency at a polite rate, see pm-api-latency. For WebSocket connect and trade publication lag, see pm-ws-latency.
Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/pm-rate-limits