How to Increase Your Polymarket Rate Limit (2026)

Which limiter are you actually hitting?

This is the whole question. Getting it wrong means emailing a team who cannot help you, or optimizing a loop that was never the problem.

A scanner reading prices meets the first. A market maker placing and pulling quotes meets the second. An application funding other users' wallets meets the third.

The Cloudflare limits are published, and fixed

Polymarket documents a specific number for every endpoint. These are IP-based, enforced through Cloudflare, and when you exceed one your requests are throttled, meaning delayed and queued, rather than rejected outright. Limits reset on sliding windows.

Two things follow from this. First, the singular plural distinction is expensive: /book allows 1,500 per 10 seconds while /books allows 500, so if you are reading many outcomes you should be comparing a batched call against three individual ones rather than assuming the batch is cheaper. Second, /markets at 300 per 10 seconds is the tightest read limit most integrations touch, and it is almost always a catalog sync that did not need to run that often.

There is no tier here. The way to have more headroom on Cloudflare limits is to need fewer requests.

The trading tiers are where the ladder is

CLOB order and cancellation requests are evaluated against per-signer token buckets, separate from the Cloudflare layer. Each signer gets an order bucket and a cancel bucket, and activity in one does not consume the other.

Tier eligibility follows the cumulative trading volume of the maker wallet, even where that differs from the signer address. The window is currently 30 days and assignments refresh every three hours.

You do not apply for these. There is no form and no review. Volume on the maker wallet moves you, and the assignment refreshes on a three-hour cycle, so a tier change follows trading rather than correspondence.

Three details that change how you build:

• Cancel budgets are double the order budgets at every tier. That is a deliberate design choice, and it means pulling quotes is never the constraint that placing them is.
• The step from Bronze to Silver is the big one. Order rate goes 80 to 200 and burst 120 to 300, a much larger jump than the steps on either side of it. Above Silver the increases flatten considerably.
• Negative cancel balances stop at Platinum. Standard through Gold allow the cancel bucket to go into debt after a cancel-all; Platinum and above floor it at zero.

Token costs are not all one. POST /order and DELETE /order cost 1. POST /orders costs the number of orders in the batch. DELETE /cancel-all and DELETE /cancel-market-orders cost 1 plus one per order actually canceled, debited after the result is known, which is how a bucket ends up in debt.

The all-or-nothing rule on batches is worth designing around: a batch is admitted only when the bucket holds enough tokens for every entry, so a batch whose cost exceeds your tier's burst capacity can never be admitted at all. At Standard, that means no single batch above 60 orders will ever succeed. Split it.

Read the headers instead of guessing

Covered requests come back with headers that tell you exactly where you stand, which removes the guesswork entirely.

Log Poly-RateLimit-Tier on startup and you will never again wonder which tier you are on. Poly-RateLimit-Remaining can be negative after a cancel-all on tiers that permit debt, so compare a batch's token cost against the remaining balance before sending it.

One timing note: the per-signer limiter entered a warning period on 24 July 2026, during which requests are processed and a header flags what would have been rejected. Polymarket said it would announce when live enforcement begins, so treat the header as the source of truth for your own account rather than assuming either state.

Where the Builder Program fits

The Builder Program is a different axis again, and it governs Relayer transactions: the gasless deposit wallet, Safe and Proxy wallet operations where Polymarket subsidizes gas.

The application wants your Builder API Key, a use case description, expected volume, and supporting material. Polymarket responds within a few business days and verification status shows in your Builder Profile settings.

Before you apply, check whether you need to. Polymarket's own guidance is that if you are not routing orders for other users' wallets, a Relayer API key from polymarket.com/settings?tab=api-keys gives you unlimited daily Relayer transactions without any application. For solo bots and personal dashboards, that is the entire fix.

Needing fewer requests in the first place

Every limiter above rewards the same discipline, and it is the only lever that works against the Cloudflare layer.

Hold a connection rather than polling. A loop re-fetching prices that have not changed is the most common cause of self-inflicted throttling, and streamed updates cost nothing against a request budget.

Cache identifiers. Slugs, condition ids and CLOB token ids are static for the life of a market. Re-resolving them every pass is how a scanner spends its /markets allowance on work it already did.

Separate your lanes. A catalog sync and a latency-sensitive order path should not share an IP or a budget, or a burst in the first delays the second exactly when it matters.

If the underlying reason you are throttled is that you are reading several venues and Polymarket simply noticed first, Predictefy serves it as one of 16 venues on a single schema with request limits published per plan:

curl -s "https://data.predictefy.com/api/polymarket/fetchMarkets?sort=volume&limit=20" \
  -H "Authorization: Bearer pk_live_YOUR_KEY"

Swap polymarket for any served venue and the request shape is unchanged. Many teams run both: the venue API for order placement, where the tier ladder above is what matters, and a normalized layer for everything they read.

Frequently Asked Questions