Polymarket API Rate Limits: The Complete Reference

If you have ever tried to answer a simple question — how many requests per second can I send to Polymarket? — you will have discovered that there is no simple answer. The limits are spread across two separate systems, published on different pages, and expressed in a 10-second window rather than the per-second or per-minute figures most APIs use.

This page collects every documented limit in one place, explains the two systems, and shows what actually happens when you cross a line. All figures come from Polymarket's official documentation and are current as of September 2026.

Two different rate limit systems

This is the part that catches most developers out. Polymarket runs two independent limiters, and being under one does not protect you from the other.

Gamma API rate limits

Base URL https://gamma-api.polymarket.com. Gamma serves market and event metadata — the endpoints most people hit first when they are exploring the platform.

Data API rate limits

Base URL https://data-api.polymarket.com. Positions, trade history and portfolio data. Note how much tighter this API is than Gamma or CLOB — the general limit is 1,000 req / 10s, a quarter of Gamma's.

CLOB API rate limits

Base URL https://clob.polymarket.com. The order book itself. CLOB has the highest general allowance of any Polymarket API (9,000 req / 10s) but splits into four distinct groups with very different limits.

General

Market data

The pattern to notice here: singular endpoints get 1,500 req / 10s, plural batch endpoints get 500 req / 10s. That looks like a downgrade until you remember one batch call covers many tokens. Batching is 3× cheaper per request but each call does far more work — always prefer /books over a loop of /book.

Ledger

Authentication

Trading — burst and sustained

Trading endpoints are the only ones with two Cloudflare limits: a burst limit for short spikes and a sustained limit measured over 10 minutes. You must stay under both.

DELETE /cancel-all at 250 req / 10s is worth flagging. Market makers who cancel-all on every re-quote cycle burn through this quickly, and the sustained limit of 6,000 per 10 minutes works out to just 10 cancel-all calls per second on average.

Bridge, Relayer and everything else

Per-signer token buckets (CLOB trading)

Separately from Cloudflare, Polymarket evaluates CLOB order and cancel requests against per-signer token buckets. Each signer address gets an order bucket and a cancel bucket; spending from one does not affect the other. Unlike the Cloudflare layer, exceeding these returns a real 429.

Requests cost tokens rather than counting as one unit each:

Volume tiers

Your bucket size depends on the maker wallet's cumulative volume over a rolling 30-day window. Tier assignments refresh every three hours.

Work out how long a full burst lasts with burst_seconds = burst / rate_per_sec. For a Standard signer that is 60 / 40 — 1.5 seconds of full-speed order submission before you are limited to the 40/s refill rate.

Reading the rate limit headers

The per-signer limiter returns headers on every evaluated request. These are the cheapest possible way to monitor your budget — no extra API calls needed.

Handling 429s properly

The correct retry strategy differs depending on which limiter you hit, and getting it wrong makes things worse. Respect Retry-After when it is present; fall back to exponential backoff with jitter when it is not. Jitter matters: without it, every one of your workers retries at the same instant and you re-trigger the limit immediately.

const MAX_RETRIES = 5;

async function polyFetch(url: string, init?: RequestInit): Promise<Response> {
  for (let attempt = 0; attempt <= MAX_RETRIES; attempt++) {
    const res = await fetch(url, init);

    // Watch the budget even on success — this is your early warning.
    const remaining = res.headers.get("Poly-RateLimit-Remaining");
    if (remaining !== null && Number(remaining) < 10) {
      console.warn(`Low token budget: ${remaining} (tier ${res.headers.get("Poly-RateLimit-Tier")})`);
    }

    // Warning mode: not rejected yet, but it would have been.
    if (res.headers.get("Poly-RateLimit-Warning") === "true") {
      console.warn("Request would be rejected under live enforcement — slow down.");
    }

    if (res.status !== 429) return res;
    if (attempt === MAX_RETRIES) return res;

    // Prefer the server's own answer, else exponential backoff.
    const retryAfter = res.headers.get("Retry-After");
    const baseMs = retryAfter
      ? Number(retryAfter) * 1000
      : Math.min(2 ** attempt * 250, 8000);

    // Full jitter — spreads a fleet of workers out instead of resynchronising them.
    await new Promise((r) => setTimeout(r, Math.random() * baseMs));
  }

  throw new Error("unreachable");
}

Staying under the limits by design

• Batch instead of looping. One /books call instead of fifty /book calls costs you one request against a 500 req/10s budget rather than fifty against a 1,500 req/10s budget — a 17× improvement in headroom.
• Cache metadata. Market metadata from /markets barely changes within a market's life, but /markets has the tightest Gamma limit at 300 req/10s. Fetch once, cache, and stop re-requesting it in your hot loop.
• Use WebSockets for live state. Polling /book on a timer is the most common way to burn a request budget. Subscribe to the stream instead and let the server push changes.
• Add jitter to scheduled jobs. If every worker wakes on the exact minute, you create a synchronised spike well above your average rate. Randomise start offsets.
• Watch latency, not just error rates. Because Cloudflare throttles rather than rejects, rising p99 latency is your first signal that you are over an IP limit — long before anything shows up as an error.
• Track the headers. Poly-RateLimit-Remaining costs nothing to read and tells you exactly how much budget is left.

Rate limits are not the same as data access

One last thing worth being explicit about, because it is the most common misconception we see: no rate limit tier gives you historical order book depth. Polymarket's API serves the current state of the book. It does not expose a historical archive of what the book looked like at 14:03:17 last Tuesday, and once a market resolves it disappears from the public feeds entirely.

That is a structural gap rather than a throttling problem, and no amount of backoff logic solves it. If you are trying to backtest a strategy, you need point-in-time snapshots that somebody recorded at the time — which is exactly what PolyTest exists to provide: 90M+ historical snapshots of Polymarket crypto Up/Down markets with full order book depth, sub-second resolution, and no gaps.