Límites de tasa de la API de Polymarket: la referencia completa

Si alguna vez has intentado responder a una pregunta sencilla (¿cuántas solicitudes por segundo puedo enviar a Polymarket?), habrás descubierto que no hay una respuesta sencilla. Los límites están repartidos en dos sistemas separados, publicados en páginas distintas y expresados en una ventana de 10 segundos en lugar de las cifras por segundo o por minuto que usan la mayoría de las APIs.

Para el límite de una ruta concreta, cada endpoint tiene además su propia página en la referencia de la API de Polymarket.

Esta página reúne todos los límites documentados en un solo lugar, explica los dos sistemas y muestra lo que pasa realmente cuando cruzas la línea. Todas las cifras salen de la documentación oficial de Polymarket y están actualizadas a septiembre de 2026.

Dos sistemas distintos de límites de tasa

Esta es la parte que pilla a la mayoría de los desarrolladores. Polymarket tiene dos limitadores independientes, y estar por debajo de uno no te protege del otro.

Límites de tasa de la API Gamma

URL base https://gamma-api.polymarket.com. Gamma sirve los metadatos de mercados y eventos, los endpoints a los que la mayoría llama primero cuando explora la plataforma.

Límites de tasa de la Data API

URL base https://data-api.polymarket.com. Posiciones, historial de operaciones y datos de cartera. Fíjate en lo mucho más estricta que es esta API que Gamma o el CLOB: el límite general es de 1,000 req / 10s, una cuarta parte del de Gamma.

Data API v2

La Data API v2 se lanzó el 4 de septiembre de 2026 en https://data-api.polymarket.com/v2 con sus propios límites. La v1 sigue funcionando pero está congelada: los nuevos endpoints y campos solo llegan a la v2.

Límites de tasa de la API CLOB

URL base https://clob.polymarket.com. El libro de órdenes en sí. El CLOB tiene la asignación general más alta de todas las APIs de Polymarket (9,000 req / 10s), pero se divide en cuatro grupos con límites muy distintos.

General

Datos de mercado

El patrón que hay que notar aquí: los endpoints singulares tienen 1,500 req / 10s y los endpoints por lotes plurales, 500 req / 10s. Parece un recorte hasta que recuerdas que una llamada por lotes cubre muchos tokens. Agrupar es 3× más barato por solicitud, pero cada llamada hace mucho más trabajo: prefiere siempre /books a un bucle de /book.

Registro

Autenticación

Trading: ráfaga y sostenido

Los endpoints de trading son los únicos con dos límites de Cloudflare: un límite de ráfaga para picos cortos y un límite sostenido medido en 10 minutos. Tienes que mantenerte por debajo de ambos.

Conviene destacar DELETE /cancel-all con 250 req / 10s. Los creadores de mercado que hacen cancel-all en cada ciclo de recotización lo agotan rápido, y el límite sostenido de 6,000 por 10 minutos equivale a solo 10 llamadas cancel-all por segundo de media.

Bridge, Relayer y todo lo demás

Token buckets por firmante (trading en el CLOB)

Aparte de Cloudflare, Polymarket evalúa las solicitudes de órdenes y cancelaciones del CLOB contra token buckets por firmante. Cada dirección de firmante tiene un bucket de órdenes y otro de cancelaciones; gastar de uno no afecta al otro. A diferencia de la capa de Cloudflare, superarlos devuelve un 429 real.

Las solicitudes cuestan tokens en lugar de contar como una unidad cada una:

Niveles de volumen

El tamaño de tu bucket depende del volumen acumulado de la wallet maker en una ventana móvil de 30 días. Las asignaciones de nivel se actualizan cada tres horas.

Calcula cuánto dura una ráfaga completa con burst_seconds = burst / rate_per_sec. Para un firmante Standard eso es 60 / 40: 1.5 segundos de envío de órdenes a toda velocidad antes de quedar limitado a la tasa de recarga de 40/s.

Leer las cabeceras de límite de tasa

El limitador por firmante devuelve cabeceras en cada solicitud evaluada. Son la forma más barata posible de vigilar tu presupuesto: no hacen falta llamadas extra a la API.

Gestionar bien los 429

La estrategia de reintento correcta depende del limitador con el que te topes, y equivocarte empeora las cosas. Respeta Retry-After cuando esté presente; si no, recurre al backoff exponencial con jitter. El jitter importa: sin él, todos tus workers reintentan en el mismo instante y vuelves a disparar el límite de inmediato.

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

Mantenerse por debajo de los límites por diseño

• Agrupa en lugar de iterar. Una llamada a /books en lugar de cincuenta llamadas a /book te cuesta una solicitud contra un presupuesto de 500 req/10s en lugar de cincuenta contra uno de 1,500 req/10s: una mejora de 17× en margen.
• Guarda los metadatos en caché. Los metadatos de mercado de /markets apenas cambian durante la vida de un mercado, pero /markets tiene el límite más estricto de Gamma, 300 req/10s. Pídelos una vez, guárdalos en caché y deja de volver a pedirlos en tu bucle caliente.
• Usa WebSockets para el estado en vivo. Hacer polling de /book con un temporizador es la forma más común de quemar un presupuesto de solicitudes. Suscríbete al stream y deja que el servidor te envíe los cambios.
• Añade jitter a las tareas programadas. Si todos los workers se despiertan en el minuto exacto, creas un pico sincronizado muy por encima de tu tasa media. Aleatoriza los desfases de inicio.
• Vigila la latencia, no solo la tasa de errores. Como Cloudflare ralentiza en lugar de rechazar, la subida de la latencia p99 es la primera señal de que estás por encima de un límite por IP, mucho antes de que aparezca nada como error.
• Sigue las cabeceras. Leer Poly-RateLimit-Remaining no cuesta nada y te dice exactamente cuánto presupuesto te queda.

Los límites de tasa no son lo mismo que el acceso a datos

Una última cosa que conviene dejar explícita, porque es el malentendido más común que vemos: ningún nivel de límite de tasa te da la profundidad histórica del libro de órdenes. La API de Polymarket sirve el estado actual del libro. No expone un archivo histórico de cómo estaba el libro a las 14:03:17 del martes pasado y, cuando un mercado se resuelve, su libro de órdenes devuelve 404.

Es un hueco estructural, no un problema de limitación, y ninguna lógica de backoff lo resuelve. Si intentas hacer backtesting de una estrategia, necesitas snapshots puntuales que alguien haya grabado en su momento, que es exactamente para lo que existe PolyTest: 240M+ snapshots históricos de los mercados cripto Up/Down de Polymarket con la profundidad completa del libro de órdenes, resolución por debajo del segundo y sin huecos.