Rate limit dell’API di Polymarket: il riferimento completo

Se hai mai provato a rispondere a una domanda semplice (quante richieste al secondo posso inviare a Polymarket?), avrai scoperto che non c’è una risposta semplice. I limiti sono distribuiti su due sistemi separati, pubblicati su pagine diverse ed espressi in una finestra di 10 secondi invece che nei valori al secondo o al minuto usati dalla maggior parte delle API.

Per il limite di una rotta specifica, ogni endpoint ha anche una pagina dedicata nel riferimento all’API di Polymarket.

Questa pagina raccoglie ogni limite documentato in un solo posto, spiega i due sistemi e mostra cosa succede davvero quando superi una soglia. Tutti i valori vengono dalla documentazione ufficiale di Polymarket e sono aggiornati a settembre 2026.

Due sistemi di rate limit diversi

È la parte che coglie impreparata la maggior parte degli sviluppatori. Polymarket usa due limitatori indipendenti, e stare sotto uno non ti protegge dall’altro.

Rate limit dell’API Gamma

URL di base https://gamma-api.polymarket.com. Gamma fornisce i metadati di mercati ed eventi, gli endpoint che la maggior parte delle persone usa per primi quando esplora la piattaforma.

Rate limit della Data API

URL di base https://data-api.polymarket.com. Posizioni, storico dei trade e dati del portafoglio. Nota quanto questa API sia più stretta di Gamma o CLOB: il limite generale è di 1,000 req / 10s, un quarto di quello di Gamma.

Data API v2

La Data API v2 è stata rilasciata il 4 settembre 2026 su https://data-api.polymarket.com/v2 con limiti propri. La v1 funziona ancora ma è congelata: i nuovi endpoint e campi arrivano solo sulla v2.

Rate limit dell’API CLOB

URL di base https://clob.polymarket.com. L’order book vero e proprio. Il CLOB ha il limite generale più alto di tutte le API di Polymarket (9,000 req / 10s), ma si divide in quattro gruppi distinti con limiti molto diversi.

Generale

Dati di mercato

Lo schema da notare: gli endpoint al singolare hanno 1,500 req / 10s, quelli batch al plurale 500 req / 10s. Sembra un peggioramento finché non ricordi che una chiamata batch copre molti token. Il batching costa un terzo per richiesta ma ogni chiamata fa molto più lavoro: preferisci sempre /books a un loop di /book.

Registro

Autenticazione

Trading: burst e sostenuto

Gli endpoint di trading sono gli unici con due limiti Cloudflare: un limite di burst per i picchi brevi e un limite sostenuto misurato su 10 minuti. Devi restare sotto entrambi.

DELETE /cancel-all a 250 req / 10s merita una segnalazione. I market maker che fanno cancel-all a ogni ciclo di ri-quotazione lo esauriscono in fretta, e il limite sostenuto di 6,000 ogni 10 minuti corrisponde in media a soli 10 cancel-all al secondo.

Bridge, Relayer e tutto il resto

Token bucket per signer (trading sul CLOB)

Separatamente da Cloudflare, Polymarket valuta le richieste di ordine e cancellazione del CLOB rispetto a token bucket per signer. Ogni indirizzo signer ha un bucket per gli ordini e uno per le cancellazioni; consumare dall’uno non influisce sull’altro. A differenza del livello Cloudflare, superarli restituisce un vero 429.

Le richieste costano token invece di contare come un’unità ciascuna:

Livelli di volume

La dimensione del tuo bucket dipende dal volume cumulativo del wallet maker su una finestra mobile di 30 giorni. L’assegnazione dei livelli si aggiorna ogni tre ore.

Calcola quanto dura un burst completo con burst_seconds = burst / rate_per_sec. Per un signer Standard è 60 / 40: 1.5 secondi di invio di ordini alla massima velocità prima di essere limitato alla velocità di ricarica di 40/s.

Leggere gli header del rate limit

Il limitatore per signer restituisce degli header su ogni richiesta valutata. Sono il modo più economico possibile per monitorare il tuo budget, senza bisogno di chiamate API aggiuntive.

Gestire correttamente i 429

La strategia di retry corretta cambia a seconda del limitatore che hai incontrato, e sbagliarla peggiora le cose. Rispetta Retry-After quando è presente; quando non c’è, ripiega su un backoff esponenziale con jitter. Il jitter conta: senza, ognuno dei tuoi worker riprova nello stesso istante e fai scattare di nuovo il limite immediatamente.

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");
}

Restare sotto i limiti per progettazione

• Usa i batch invece dei loop. Una chiamata /books invece di cinquanta chiamate /book ti costa una richiesta su un budget di 500 req/10s invece di cinquanta su un budget di 1,500 req/10s: un margine 17 volte migliore.
• Metti in cache i metadati. I metadati dei mercati di /markets cambiano pochissimo durante la vita di un mercato, ma /markets ha il limite Gamma più stretto, 300 req/10s. Scaricali una volta, mettili in cache e smetti di richiederli nel tuo ciclo critico.
• Usa i WebSocket per lo stato live. Fare polling di /book a intervalli regolari è il modo più comune di bruciare un budget di richieste. Iscriviti allo stream e lascia che sia il server a inviarti le modifiche.
• Aggiungi jitter ai job schedulati. Se ogni worker si sveglia esattamente allo scoccare del minuto, crei un picco sincronizzato ben sopra la tua frequenza media. Randomizza gli offset di avvio.
• Guarda la latenza, non solo i tassi di errore. Poiché Cloudflare rallenta invece di rifiutare, l’aumento della latenza p99 è il tuo primo segnale di aver superato un limite per IP, molto prima che qualcosa compaia come errore.
• Tieni traccia degli header. Leggere Poly-RateLimit-Remaining non costa nulla e ti dice esattamente quanto budget ti resta.

I rate limit non sono la stessa cosa dell’accesso ai dati

Un’ultima cosa da chiarire in modo esplicito, perché è il malinteso più comune che vediamo: nessun livello di rate limit ti dà la profondità storica dell’order book. L’API di Polymarket fornisce lo stato attuale del book. Non espone un archivio storico di com’era il book alle 14:03:17 di martedì scorso, e una volta che un mercato si risolve il suo order book restituisce 404.

È una lacuna strutturale, non un problema di rallentamento, e nessuna logica di backoff la risolve. Se stai cercando di fare backtest di una strategia, ti servono snapshot point-in-time registrati da qualcuno all’epoca, ed è esattamente ciò per cui esiste PolyTest: 240M+ snapshot storici dei mercati crypto Up/Down di Polymarket con profondità completa dell’order book, risoluzione sotto il secondo e nessun buco.