Polymarket API rate limits — Gamma, Data & CLOB

Polymarket API rate limits are the throttles you must design around when building bots, dashboards, or analytics. This guide lays out the documented limits for each public surface (Gamma, Data, CLOB, and the Market WebSocket), explains the important Gamma /markets constraints (including the /markets 300 req / 10 s rule and cursor-based pagination), and gives concrete strategies—batching, caching, cursor pagination, exponential backoff—to keep your client reliable under load.

Key takeaways

• Gamma's /markets endpoint: 300 requests per 10 seconds; use the limit parameter and after_cursor for pagination (do not use offset).
• Combined listing limits: /markets + /events listing calls share a 900 req / 10 s cap; Gamma overall: 4000 req / 10 s.
• Use the CLOB and Data APIs for specialized reads; CLOB requires API key + HMAC for trading calls, reads are public.
• WebSocket (wss://ws-subscriptions-clob.polymarket.com/ws/market) provides real-time data; prefer WS for live book updates instead of polling.
• Mitigation patterns: request coalescing, caching TTLs, exponential backoff with jitter, rate-aware queuing, and pagination-aware fetching.

Why rate limits matter

Rate limits protect Polymarket's shared infrastructure and prevent noisy clients from degrading the experience for others. For developers building arbitrage bots or analytics systems, hitting a limit causes immediate request rejection and can break time-sensitive flows. Planning request patterns up front reduces surprises and makes systems more robust.

Documented Polymarket rate limits and endpoints

Gamma (primary market metadata)

• Base URL: https://gamma-api.polymarket.com
• Notable limits:
  • /markets: max 300 requests per 10 seconds. Use the limit parameter (max 1000) and cursor-based pagination via after_cursor. The API rejects offset with HTTP 422.
  • Combined /markets + /events listing limit: 900 requests per 10 seconds.
  • Overall Gamma API surface: 4000 requests per 10 seconds.

Practical notes:

• Always prefer after_cursor returned by the previous call; do not attempt keyset emulation using offset.
• Tune limit to reduce round trips. If you need full market lists, limit=1000 reduces calls.

Data (positions, trades, holders)

• Base URL: https://data-api.polymarket.com
• Auth: None for public reads.
• The brief documents the surface but does not list per-endpoint rate numbers for Data. Treat Data as public, but implement the same conservative client-side controls as Gamma (batching, caching, backoff).

CLOB (order book and trading)

• Base URL: https://clob.polymarket.com
• Reads are public. Trading requires API key + HMAC.
• The CLOB surface exposes order book, midpoint, price history, and order placement/cancellation. The doc does not publish explicit per-endpoint rate numbers for CLOB reads; treat trading paths as rate-sensitive and use the CLOB WebSocket or the Market WS for live book data when possible.

Market WebSocket (real-time market updates)

• URL: wss://ws-subscriptions-clob.polymarket.com/ws/market
• No auth required for market data.
• Feeds: real-time book, price_change, best_bid_ask (enable with custom_feature_enabled: true), last_trade_price, tick_size_change.
• PING heartbeat every 10 seconds. Max 500 instruments per connection.

Gamma /markets specifics you must follow

• Pagination: after_cursor only. The API returns next_cursor — pass it unchanged to the next call.
• limit default is 20, max 1000. Use larger limit for bulk-syncs.
• Filter parameters accepted include arrays for slug, id, condition_ids, clob_token_ids, question_ids, market_maker_address and others like closed, active, archived, tag_id.
• Ordering: order accepts comma-separated field lists (e.g. volume24hr,liquidity) and ascending is boolean with default true.

Common error signals and how to react

• HTTP 429 (rate limited): stop immediate polling, back off, and retry with exponential backoff and jitter.
• HTTP 422 when using offset: switch to after_cursor pagination.
• Partial responses or empty pages: honor cursors; verify your filters. If you believe you hit a server-side quota, reduce client request concurrency.

Design patterns to avoid throttles

1. Cache aggressively

• Cache market lists and metadata for short TTLs (30s–2m) depending on use. Markets and event lists rarely change every second.
• Cache by query key (filters + order). Invalidate the cache only when you receive change events (e.g., from WebSocket) or after TTL expiry.

2. Batch and increase limit

• For full-syncs, use limit=1000 to reduce round trips against /markets.
• Pull wide pages during off-peak windows and use incremental updates from the WebSocket.

3. Use the WebSocket for real-time data

• For live order-book updates or price movements, subscribe to the Market WS rather than polling Gamma or CLOB reads. The WS supports up to 500 instruments per connection; shard clients if you need >500.

4. Rate-aware queuing and backoff

• Implement a leaky-bucket or token-bucket client-side limiter that matches documented peaks (e.g., 300/10s for /markets).
• When you receive 429, apply exponential backoff with jitter and progressively increase your retry window.

5. Coalesce identical concurrent requests

• If multiple parts of your app request the same /markets query simultaneously, coalesce them to a single in-flight request and fan out the response.

6. Cursor-first synchronization

• Always follow cursor-based pagination. For live syncs, request the first page then subscribe to deltas if supported. Do not attempt naive concurrent cursored fetches that could exceed Gamma's per-endpoint limit.

Example fetch strategies

• Bulk indexing job (non-real-time): fetch /markets?limit=1000 then follow next_cursor until exhausted. Sleep briefly between pages, and respect the 300/10s endpoint limit.
• Near-real-time UI: fetch base set once (cache 30s), then open WebSocket for deltas and best_bid_ask updates.
• Watchlist micro-client: shard watchlists across multiple WS connections if >500 instruments.

Operational guidance for bots and high-throughput clients

• Use the CLOB WebSocket or CLOB reads for book-level data and Gamma for slower metadata.
• Keep trading credentials (CLOB API key + HMAC) secure; trading endpoints are authenticated.
• Monitor your 429 rate and instrument per-endpoint latency metrics. If you regularly approach documented caps, request access or reach out via official Polymarket channels (the Builder Program is the path for higher-volume integrations and attribution).

How this affects your development and deployment

If you build a trading bot or analytics service, plan for layered data flows: an initial bulk fetch from Gamma with large limit, followed by WebSocket subscriptions for live updates, and a small set of periodic Gamma polls (cached) for any metadata not in the WS feed. Implement client-side rate limiting, coalescing, and cursor-aware pagination to avoid hitting the documented /markets 300 req / 10 s cap and the combined listing and overall Gamma caps.

Closing summary

Polymarket API rate limits are explicit for Gamma's listing surfaces and the Market WS offers a scalable alternative for live feeds. Design around cursor-based pagination (after_cursor), use limit strategically, and prefer WebSockets for high-frequency data. Following these patterns will reduce throttling and make your integrations more reliable.

Frequently asked questions

What is the /markets rate limit on Gamma?

Gamma's /markets endpoint is limited to 300 requests per 10 seconds. Use limit (max 1000) and cursor-based pagination via after_cursor. Do not use offset—the API rejects it with HTTP 422.

Are there combined limits for Gamma endpoints?

Yes. Listing calls to /markets and /events share a combined cap of 900 requests per 10 seconds. Additionally, the overall Gamma API surface is limited to 4000 requests per 10 seconds.

Should I poll Gamma or use the WebSocket for live updates?

Prefer the Market WebSocket (wss://ws-subscriptions-clob.polymarket.com/ws/market) for live book and price updates—it's more efficient and avoids repeated polling. Use Gamma for slower-changing metadata and initial bulk syncs.

What should my client do on HTTP 429 responses?

Treat 429 as a signal to stop aggressive polling. Implement exponential backoff with jitter, reduce concurrency, and coalesce identical requests. Track 429s to adjust your rate limiter dynamically.

Does the CLOB API require authentication?

CLOB reads are public. Trading operations on CLOB require an API key plus HMAC authentication. Respect trading rate limits and prefer WS feeds for book updates.