Limites de requisições da API da Polymarket: a referência completa

Se você já tentou responder a uma pergunta simples — quantas requisições por segundo posso enviar para a Polymarket? —, deve ter descoberto que não há resposta simples. Os limites estão espalhados por dois sistemas separados, publicados em páginas diferentes e expressos em uma janela de 10 segundos, em vez dos números por segundo ou por minuto que a maioria das APIs usa.

Para o limite de uma rota específica, cada endpoint também tem sua própria página na referência da API da Polymarket.

Esta página reúne todos os limites documentados em um só lugar, explica os dois sistemas e mostra o que realmente acontece quando você passa da linha. Todos os números vêm da documentação oficial da Polymarket e estão atualizados até setembro de 2026.

Dois sistemas diferentes de limite de requisições

Esta é a parte que pega a maioria dos desenvolvedores. A Polymarket roda dois limitadores independentes, e estar abaixo de um não protege você do outro.

Limites da API Gamma

URL base https://gamma-api.polymarket.com. A Gamma serve os metadados de mercados e eventos — os endpoints que a maioria das pessoas acessa primeiro ao explorar a plataforma.

Limites da Data API

URL base https://data-api.polymarket.com. Posições, histórico de negociações e dados de portfólio. Note quanto esta API é mais apertada do que a Gamma ou o CLOB — o limite geral é de 1,000 req / 10s, um quarto do da Gamma.

Data API v2

A Data API v2 foi lançada em 4 de setembro de 2026 em https://data-api.polymarket.com/v2, com seus próprios limites. A v1 continua no ar, mas está congelada — novos endpoints e campos só chegam na v2.

Limites da API CLOB

URL base https://clob.polymarket.com. O livro de ofertas em si. O CLOB tem a maior cota geral de todas as APIs da Polymarket (9,000 req / 10s), mas se divide em quatro grupos distintos, com limites muito diferentes.

Geral

Dados de mercado

O padrão a notar aqui: os endpoints no singular têm 1,500 req / 10s, os endpoints de lote no plural têm 500 req / 10s. Parece um rebaixamento até você lembrar que uma chamada em lote cobre muitos tokens. O lote custa 3× menos por requisição, mas cada chamada faz muito mais trabalho — prefira sempre /books a um loop de /book.

Registro

Autenticação

Trading — pico e sustentado

Os endpoints de trading são os únicos com dois limites da Cloudflare: um limite de pico para picos curtos e um limite sustentado medido ao longo de 10 minutos. Você precisa ficar abaixo dos dois.

Vale destacar o DELETE /cancel-all com 250 req / 10s. Market makers que fazem cancel-all a cada ciclo de recotação esgotam esse limite rapidamente, e o limite sustentado de 6,000 a cada 10 minutos dá, em média, só 10 chamadas de cancel-all por segundo.

Bridge, Relayer e todo o resto

Token buckets por signer (trading no CLOB)

Separadamente da Cloudflare, a Polymarket avalia as requisições de ordem e cancelamento do CLOB com token buckets por signer. Cada endereço de signer tem um bucket de ordens e um bucket de cancelamentos; gastar de um não afeta o outro. Diferentemente da camada da Cloudflare, exceder esses limites retorna um 429 de verdade.

As requisições custam tokens, em vez de contarem como uma unidade cada:

Níveis de volume

O tamanho do seu bucket depende do volume acumulado da carteira maker em uma janela móvel de 30 dias. A atribuição de nível é atualizada a cada três horas.

Calcule quanto dura um pico completo com burst_seconds = burst / rate_per_sec. Para um signer Standard, isso dá 60 / 40 — 1.5 segundo de envio de ordens a toda velocidade antes de você ficar limitado à taxa de recarga de 40/s.

Lendo os headers de limite de requisições

O limitador por signer retorna headers em toda requisição avaliada. Eles são a forma mais barata possível de monitorar seu orçamento — nenhuma chamada extra à API é necessária.

Tratando os 429 corretamente

A estratégia certa de nova tentativa muda conforme o limitador que você atingiu, e errar piora as coisas. Respeite o Retry-After quando ele estiver presente; recorra ao backoff exponencial com jitter quando não estiver. O jitter importa: sem ele, todos os seus workers tentam de novo no mesmo instante e você dispara o limite de novo na hora.

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

Ficando abaixo dos limites por design

• Use lotes em vez de loops. Uma chamada a /books em vez de cinquenta chamadas a /book custa uma requisição contra um orçamento de 500 req/10s, em vez de cinquenta contra um de 1,500 req/10s — uma folga 17× maior.
• Guarde os metadados em cache. Os metadados de mercado de /markets quase não mudam durante a vida de um mercado, mas /markets tem o limite mais apertado da Gamma, 300 req/10s. Busque uma vez, guarde em cache e pare de pedi-los de novo no seu loop quente.
• Use WebSockets para o estado ao vivo. Fazer polling de /book com um timer é a forma mais comum de queimar o orçamento de requisições. Assine o stream e deixe o servidor enviar as mudanças.
• Adicione jitter aos jobs agendados. Se todos os workers acordam exatamente na virada do minuto, você cria um pico sincronizado bem acima da sua taxa média. Torne aleatórios os deslocamentos de início.
• Observe a latência, não só as taxas de erro. Como a Cloudflare atrasa em vez de rejeitar, a latência p99 subindo é o primeiro sinal de que você passou de um limite por IP — muito antes de qualquer coisa aparecer como erro.
• Acompanhe os headers. Ler Poly-RateLimit-Remaining não custa nada e diz exatamente quanto orçamento resta.

Limites de requisições não são o mesmo que acesso a dados

Uma última coisa que vale deixar explícita, porque é o equívoco mais comum que vemos: nenhum nível de limite de requisições dá acesso à profundidade histórica do livro de ofertas. A API da Polymarket serve o estado atual do livro. Ela não expõe um arquivo histórico de como estava o livro às 14:03:17 da última terça-feira, e depois que um mercado é resolvido o livro de ofertas dele retorna 404.

Isso é uma lacuna estrutural, e não um problema de limitação, e nenhuma lógica de backoff resolve. Se você está tentando fazer backtest de uma estratégia, precisa de snapshots pontuais que alguém gravou na época — que é exatamente o que a PolyTest existe para oferecer: mais de 240M de snapshots históricos dos mercados cripto Up/Down da Polymarket, com profundidade completa do livro de ofertas, resolução abaixo de um segundo e sem lacunas.