Cómo elegir una API de datos de Polymarket

Si estás buscando datos históricos de Polymarket, ya te has topado con el muro que trae aquí a todo el mundo: la API de Polymarket solo sirve el estado actual. Pide el libro de órdenes de un mercado resuelto y recibirás un 404; el historial de precios que conserva tiene aproximadamente un punto por minuto, sin nada sobre la profundidad. Ninguna de las dos cosas depende del plan. El libro simplemente no está.

Así que necesitas un proveedor que haya grabado el libro mientras los mercados estaban activos. El problema es que todos los proveedores de este sector venden la misma cifra principal, y es casi la menos informativa que existe. Esto es lo que debes comprobar en su lugar.

1. Snapshots por mercado y minuto, no snapshots totales

El número total de snapshots es la cifra estrella en todas partes, y casi no significa nada. Un total es solo la tasa de captura × los mercados registrados × el tiempo de recopilación. Un proveedor con una cifra mayor puede tener mejor resolución, o simplemente llevar más tiempo recopilando, o estar contando filas redundantes de mercados que nadie negocia.

Lo que de verdad necesitas saber es: en el mercado concreto que me interesa, ¿cuántos snapshots por minuto obtengo? Un mercado de 5 minutos muestreado dos veces por minuto te da diez puntos de datos para modelar todo el ciclo de vida de un mercado. Eso no basta para probar nada.

# Pull the same market from each provider, then compare density.
snaps = fetch_snapshots(market_id)          # provider-specific call

span_s  = (snaps[-1]["timestamp"] - snaps[0]["timestamp"]) / 1000
per_min = len(snaps) / (span_s / 60)

print(f"{len(snaps)} snapshots over {span_s:.0f}s = {per_min:.1f}/min")

# Gaps matter more than the average. One 90-second hole in a 5-minute
# market means you cannot model the part where it was decided.
gaps = [
    (b["timestamp"] - a["timestamp"]) / 1000
    for a, b in zip(snaps, snaps[1:])
]
print(f"max gap: {max(gaps):.1f}s   median: {sorted(gaps)[len(gaps)//2]:.1f}s")

2. ¿Profundidad real del libro o solo el mejor nivel?

Es el factor que más determina si tu backtest significa algo, y es donde el lenguaje del marketing se vuelve más resbaladizo. “Datos del libro de órdenes” puede significar cualquier cosa, desde la escalera completa hasta un único par bid/ask.

Si piensas operar con un tamaño significativo, necesitas la escalera. Una orden de 500 acciones en un mercado Up/Down poco líquido no se ejecuta en el primer nivel: recorre el libro, y la diferencia entre el primer nivel y tu precio medio de ejecución real suele ser mayor que la ventaja que estás probando.

def simulate_fill(levels, qty):
    """Walk the ladder. This is what actually happens to your order."""
    filled = cost = 0.0
    for lvl in levels:
        take = min(lvl["size"], qty - filled)
        cost += take * lvl["price"]
        filled += take
        if filled >= qty:
            break
    if filled < qty:
        return None            # Not enough liquidity to fill at all.
    return cost / filled

book = snapshot["orderbook"]["asks"]
print("top of book:", book[0]["price"])
print("true fill  :", simulate_fill(book, 500))
# A gap of 2-3c here on a $1 binary is routine, and it is
# larger than most claimed edges.

3. ¿De verdad se conservan los mercados resueltos?

El único motivo para pagar por estos datos es que Polymarket los descarta. Así que verifica que el proveedor realmente los conserva, en lugar de hacer de proxy de los endpoints en vivo con una caché.

La prueba lleva un minuto: busca un mercado que se resolvió hace semanas, pide sus snapshots y confirma que obtienes una trayectoria de precios completa con profundidad, no solo un registro de metadatos que dice qué lado ganó. Conocer el resultado no son datos; cualquier estrategia que merezca la pena probar trata del camino, no de la respuesta.

4. Ventana de historial frente a profundidad de historial

Los proveedores venden el historial de dos formas distintas, y la diferencia importa más que el número bruto de días:

• Una ventana móvil: los N días más recientes, y los datos más antiguos van caducando. Suficiente para ajustar a las condiciones actuales del mercado.
• Un archivo conservado: todo desde que empezó la recopilación. Necesario si quieres probar en distintos regímenes de volatilidad.

Cuál necesitas depende, sinceramente, de tu estrategia. Si operas en mercados de 5 minutos y reajustas cada semana, 30 días son más que suficientes y pagar por más es un desperdicio. Si quieres saber si tu ventaja sobrevivió a las condiciones del año pasado, una ventana móvil no puede responderlo a ningún precio.

5. Rendimiento que de verdad puedas usar

Los límites de tasa parecen un detalle hasta que ejecutas tu primer backtest real. Descargar todos los snapshots de un mes de mercados de 5 minutos de tres monedas son muchas solicitudes, y un límite de 10 req/s convierte una tarde de investigación en un trabajo de toda la noche.

Importan dos cifras y los proveedores a menudo publican solo una: el rendimiento sostenido (solicitudes por minuto) y la capacidad de ráfaga (solicitudes por segundo). Un límite por minuto alto con una ráfaga baja sigue atascando una descarga en paralelo.

Si descargas historial masivo con regularidad, pregunta también si hay una vía de exportación masiva. Paginar un millón de snapshots a través de un endpoint REST es posible, pero no es la herramienta adecuada.

6. ¿Puedes evaluarlo antes de pagar?

No puedes evaluar la calidad de los datos desde una página de marketing. Cualquier proveedor seguro de sus datos te dejará verlos antes de pagar, mediante un plan gratuito o una prueba, e idealmente con una referencia de la API que puedas leer sin registrarte.

Eso sí, ten claro para qué sirve un plan gratuito o una prueba. La nuestra es una prueba de 3 días del plan Builder completo, con profundidad del libro de órdenes incluida, para que puedas comprobar la cobertura, la densidad de snapshots y la forma de las respuestas antes de comprometerte; pero tres días y una ventana de 14 días la convierten en una herramienta de evaluación, no en un plan de investigación. Sea cual sea el proveedor, averigua qué partes se pueden usar gratis de verdad antes de sacar conclusiones.

7. ¿Tus herramientas pueden leer la documentación?

Una consideración más reciente, y que vale la pena comprobar porque es invisible hasta que te muerde. Si programas con Cursor, Claude Code o Codex, la capacidad de tu asistente para escribir una integración correcta depende de que pueda leer la documentación del proveedor.

Algunos proveedores de datos bloquean los crawlers de IA en robots.txt, una decisión legítima sobre los datos de entrenamiento, pero que implica que los modelos no pueden ver su documentación e improvisarán la API. Puedes comprobar cualquier proveedor en unos cinco segundos:

curl -s https://<provider>/robots.txt | grep -iA1 "GPTBot\|ClaudeBot\|Google-Extended"

# "Disallow: /" under those agents means your AI assistant
# cannot read their docs and will guess at the API instead.

Como referencia, PolyTest permite esos crawlers y publica llms.txt, llms-full.txt y una especificación OpenAPI. Aun así, la prueba práctica es más sencilla que leer archivos de políticas: pide a tu asistente que escriba una integración con cada proveedor y mira cuál produce código que funciona.

Cuándo no deberías pagar a nadie

Vale la pena decirlo claro, porque se aplica a nosotros tanto como a cualquiera. No necesitas un proveedor de datos de pago si:

• Solo necesitas datos en vivo. La API pública y los streams WebSocket de Polymarket son gratuitos, no requieren autenticación para los datos de mercado y funcionan perfectamente. Los proveedores históricos existen para el historial, nada más.
• Estás probando infraestructura, no una estrategia. La autenticación, el parsing, las reconexiones y la gestión de límites de tasa se pueden ejercitar contra los endpoints en vivo gratuitos.
• Tu estrategia no depende de las ejecuciones. Si estudias tasas base o frecuencias de resolución, esa información sobrevive en los metadatos públicos.
• Estás dispuesto a grabarlo tú mismo. Tener un recolector conectado al WebSocket público es totalmente viable. Cuesta un servidor pequeño y la disciplina de mantenerlo en marcha; el problema es que empiezas sin historial y no puedes rellenar hacia atrás, así que solo ayuda si empiezas mucho antes de necesitar los datos.

El argumento para pagar es estrecho y concreto: quieres historial que no grabaste, a partir de hoy.

Una prueba que puedes hacer esta tarde

1. Regístrate en el plan gratuito o la prueba de cada proveedor de tu lista.
2. Elige un mercado (misma moneda, mismo intervalo, mismo día) y descárgalo de cada uno.
3. Compara los snapshots por minuto y el hueco máximo. La densidad y la continuidad ganan a cualquier cifra estrella.
4. Comprueba los niveles del libro por snapshot. Si no es una escalera, no puedes modelar las ejecuciones.
5. Pide un mercado que se resolvió hace un mes y confirma que obtienes una trayectoria completa, no solo un resultado.
6. Ejecuta tu patrón de consultas realista más pesado y mira qué proveedor te limita primero.
7. Pide a tu asistente de IA que escriba una integración con cada uno y comprueba qué documentación puede leer de verdad.

Esa secuencia lleva una tarde y te dice más que cualquier tabla comparativa, incluida esta. Si quieres empezar con la nuestra, hay una prueba gratuita de 3 días, y la referencia de endpoints se puede leer sin registrarte.