¿Es gratis la API de Polymarket? Datos públicos, autenticación y coste real de ejecutar un bot

Respuesta directa y alcance de esta guía

Sí, la API de Polymarket es gratuita. Polymarket no vende acceso a la API. No hay nivel de pago, ni factura por solicitud, ni clave API que comprar. Los datos públicos de mercado, los libros de órdenes, el historial de precios y los metadatos de eventos se pueden leer sin autenticación, y la colocación de órdenes se autentica con tu billetera en lugar de una cuenta de facturación.

Esa respuesta es breve, pero no es el panorama completo de costes. La pregunta "is polymarket api free" (¿es gratis la API de Polymarket) suele esconder una segunda pregunta: ¿cuánto me costará ejecutar algo sobre ella? Esta guía separa tres cosas que son fáciles de confundir: el acceso gratuito documentado, los costes indirectos de los límites de velocidad y la indexación autogestionada, y los costes de infraestructura que debes medir tú mismo. No publica números de referencia inventados; te da un procedimiento para producir los tuyos propios.

• Gratis: lecturas públicas de mercados, eventos, libros de órdenes y precios.
• Gratis: colocación y cancelación de órdenes, autenticadas mediante firma de billetera.
• No gratis: tu tiempo para construir la indexación histórica, y la capacidad de RPC o nodo detrás de cualquier lectura o escritura en cadena.
• No gratis: proveedores de datos de terceros que revenden el historial indexado de Polymarket.

Suposiciones y requisitos previos

Este artículo asume que eres un desarrollador que evalúa Polymarket como fuente de datos o lugar de ejecución. Deberías sentirte cómodo con HTTP, JSON y un lenguaje de scripting. Los ejemplos usan curl y Python porque son el camino más corto a un resultado verificable.

No necesitas una cuenta para seguir los ejemplos de solo lectura. Para el ejemplo de trading necesitas una billetera con fondos en Polygon y una comprensión clara de que colocar una orden es una acción financiera real. Trata cada ejemplo de escritura como código de producción, no como un juguete de sandbox.

• Python 3.9 o superior con la librería requests.
• curl para comprobaciones rápidas de endpoints.
• Una billetera Polygon solo si pretendes operar; nunca confirmes una clave privada.
• Un endpoint RPC si planeas leer el estado de la cadena o enviar transacciones directamente.

Cómo funciona realmente el modelo de acceso gratuito

Polymarket expone varias superficies distintas, y son gratuitas por diferentes razones. La API Gamma es la capa de descubrimiento: mercados, eventos, etiquetas y metadatos. Es pública y no requiere autenticación para lecturas. La API CLOB es la capa de trading: libros de órdenes, precios y gestión de órdenes. Sus endpoints de lectura son públicos, y sus endpoints de escritura autentican la billetera que firma la orden.

Debido a que la autenticación se basa en la billetera en lugar de una cuenta, no hay una relación de facturación que medir. Polymarket no te cobra por llamada; protege el lugar con límites de velocidad y verificaciones de firma. Esa distinción importa cuando planificas la capacidad: tu techo no es una línea presupuestaria, es un techo de tasa de solicitudes y un flujo de trabajo de firma.

Un modelo mental útil es una biblioteca pública con un mostrador de trading dentro. Cualquiera puede entrar y leer el catálogo y los estantes. Para colocar una orden en el mostrador debes demostrar quién eres con una firma, pero sigues sin pagar una tarifa de entrada. Lo que pagas es el transporte para llegar allí y el personal que contratas para trabajar los estantes de manera eficiente.

Verificar lecturas públicas gratuitas con curl

La forma más rápida de confirmar que las lecturas públicas no requieren autenticación es llamar a un endpoint de lectura sin encabezados más allá de los predeterminados. Si obtienes JSON estructurado de vuelta, el endpoint está abierto. Ejecuta estos contra los hosts base documentados e inspecciona el código de estado y la forma del cuerpo.

Los nombres de host y las rutas exactas están documentados por Polymarket y pueden cambiar; sustituye la URL base documentada actual donde aparece el marcador de posición. El propósito del ejercicio es el comportamiento, no una URL codificada.

# Confirm an unauthenticated read returns JSON
curl -sS -o /tmp/markets.json -w "%{http_code}\n" \
  "https://GAMMA_API_HOST/markets?limit=5"

# Inspect the shape without dumping the whole payload
python3 - <<'PY'
import json
with open('/tmp/markets.json') as f:
    data = json.load(f)
print(type(data).__name__, len(data) if hasattr(data, '__len__') else '')
first = data[0] if isinstance(data, list) and data else data
print(sorted(first.keys())[:12] if isinstance(first, dict) else first)
PY

Resultado esperado de la verificación

Una lectura no autenticada exitosa devuelve HTTP 200 y un array u objeto JSON. Si en cambio recibes 401 o 403, estás llamando a un endpoint autenticado o el host ha cambiado. Si recibes 429, has alcanzado un límite de velocidad, que es la primera señal de coste real que encontrarás.

Registra el resultado en una pequeña tabla para que puedas comparar endpoints y luego comparar tus propias ejecuciones. No rellenes números que no hayas observado; deja las celdas en blanco hasta que ejecutes la comprobación.

• | Comprobación | Esperado | Observado |
• | Lectura pública de mercados | 200, JSON | (registra tu resultado) |
• | Lectura pública del libro de órdenes | 200, JSON | (registra tu resultado) |
• | Colocación de orden autenticada sin firma | 401/403 | (registra tu resultado) |
• | Ráfaga de lecturas más allá de tu presupuesto | 429 | (registra tu resultado) |

Dónde la autenticación cambia el panorama de costes

Los endpoints de trading requieren una orden firmada. La firma prueba que la billetera controla los fondos; no genera una factura. El coste práctico es operativo: debes gestionar las claves de forma segura, firmar correctamente y manejar errores de nonce y de estado de la orden. Un bot que reintenta una firma fallida puede enviar dos veces, y eso es una pérdida financiera, no una tarifa de API.

El otro coste adyacente a la autenticación es la capa RPC. Si tu bot lee el estado en cadena, verifica saldos o envía transacciones directamente, estás consumiendo capacidad RPC. Esa capacidad es donde una API gratuita aún puede generar una factura mensual. Para un tratamiento más amplio de la selección de endpoints, consulta la guía de endpoints RPC y el directorio de redes.

• Las firmas de billetera reemplazan a las claves API para escrituras.
• La gestión de claves y la lógica de reintentos son tu responsabilidad.
• Las lecturas en cadena y el envío de transacciones consumen capacidad RPC, que es un centro de coste separado.

Medir tu coste real con una prueba de carga reproducible

Dado que Polymarket no publica una lista de precios para el acceso a la API, la única estimación honesta de costes es la que mides tú mismo. Construye un pequeño arnés que emita lecturas a una tasa controlada, registre códigos de estado y latencia, y se detenga cuando vea 429. Ejecútalo contra una copia de pruebas de tu lógica, nunca contra el flujo de órdenes de producción.

El script a continuación es deliberadamente conservador. Aumenta la tasa de solicitudes en pasos, registra la primera respuesta de límite de velocidad e imprime una tabla que puedes pegar en tus propias notas. No inventa un límite; descubre el límite que tu cliente observa en ese momento.

import time, statistics, requests

BASE = "https://GAMMA_API_HOST"  # replace with documented host
PATH = "/markets"

def probe(rate_per_sec, duration=10):
    interval = 1.0 / rate_per_sec
    latencies, codes = [], []
    start = time.time()
    while time.time() - start < duration:
        t0 = time.time()
        try:
            r = requests.get(BASE + PATH, params={"limit": 5}, timeout=5)
            codes.append(r.status_code)
        except requests.RequestException as e:
            codes.append(type(e).__name__)
        latencies.append((time.time() - t0) * 1000)
        time.sleep(max(0, interval - (time.time() - t0)))
    return codes, latencies

print("rate | n | 429s | p50_ms | p95_ms")
for rate in (1, 2, 5, 10):
    codes, lat = probe(rate)
    n429 = sum(1 for c in codes if c == 429)
    p50 = statistics.median(lat)
    p95 = sorted(lat)[int(len(lat) * 0.95) - 1]
    print(f"{rate:>4} | {len(codes):>3} | {n429:>4} | {p50:>6.1f} | {p95:>6.1f}")

Leer la tabla de resultados sin engañarte a ti mismo

Tu tabla mostrará una tasa a la que aparecen los 429. Ese número es específico de tu IP, tu cliente y el momento en que ejecutaste la prueba. No es una cuota publicada y puede cambiar. Úsalo como dato de planificación, no como contrato.

La columna más útil es la latencia p95. Si la latencia aumenta bruscamente antes de que aparezcan los 429, tu cliente ya está cerca de un techo suave y debería retroceder. Un cliente bien comportado utiliza retroceso exponencial con jitter y almacena en caché las respuestas que no cambian con frecuencia, como los metadatos de mercado. El almacenamiento en caché es la mitigación de límite de velocidad más barata disponible y no cuesta más que un diccionario y un TTL.

• Trata los umbrales de 429 observados como específicos del entorno, no universales.
• Almacena en caché agresivamente los metadatos que cambian lentamente.
• Retrocede ante el crecimiento de la latencia, no solo ante 429 explícitos.
• Vuelve a ejecutar el arnés después de cualquier cambio en tu patrón de solicitudes.

Solución de problemas comunes del nivel gratuito

La mayoría de las sorpresas no son sorpresas de facturación; son sorpresas de comportamiento. Una lectura que funcionaba ayer devuelve 401 hoy porque la ruta se movió a una superficie autenticada. Una ráfaga que estaba bien en desarrollo provoca 429 en producción porque un segundo proceso comparte la misma IP de salida. Una consulta histórica devuelve solo una ventana reciente porque la API pública no es un archivo completo.

Resuélvelos en orden: confirma que el endpoint está documentado como público, confirma que no compartes una IP de salida con un proceso ruidoso, confirma que tu cliente respeta Retry-After y confirma que no esperas un historial que la superficie pública no sirve.

• 401/403: el endpoint está autenticado o el host cambió.
• 429: límite de velocidad; respeta Retry-After y añade jitter.
• Historial vacío: la API pública no es un archivo completo; necesitas tu propia indexación o un proveedor de datos.
• Estado de orden inconsistente: manejo de firma o nonce, no una tarifa de API.

Limitaciones y compensaciones del modelo gratuito

El acceso gratuito es generoso, pero no es un acuerdo de nivel de servicio. No hay un nivel de pago para comprar prioridad, por lo que tu rendimiento está limitado por límites compartidos y tu propia ingeniería. Si necesitas capacidad garantizada, agregación entre mercados o rellenos históricos largos, la respuesta honesta es que pagarás a alguien, ya sea en infraestructura o en una suscripción de datos.

La compensación es sencilla. La API gratuita es excelente para descubrimiento, paneles de control y trading de frecuencia moderada. Encaja mal para estrategias de alta frecuencia que necesitan rendimiento dedicado, y no sustituye a un indexador si necesitas años de historial de operaciones. Planifica esa brecha explícitamente en lugar de descubrirla en producción.

• Sin nivel de pago significa sin prioridad comprada.
• La profundidad histórica es limitada en las superficies públicas.
• Las estrategias de alta frecuencia necesitan infraestructura dedicada.
• Los indexadores de terceros cubren la brecha histórica a un coste real.

Próximos pasos para una construcción consciente de los costes

Comienza con las lecturas gratuitas y una capa de caché. Mide tu techo de tasa observado con el arnés anterior. Luego decide si tu carga de trabajo necesita capacidad RPC dedicada para lecturas en cadena y envío de transacciones. Si es así, compara opciones de nodos dedicados y revisa los precios de RPC antes de escalar.

Para elecciones concretas de endpoints y proveedores, usa el Asistente RPC en lugar de adivinar. Mantiene la recomendación breve y actualizada, mientras esta guía se centra en el método. Una secuencia sensata es: verificar lecturas gratuitas, medir límites, añadir caché y luego aprovisionar infraestructura solo para las partes que realmente la necesitan.

• Verifica las lecturas públicas y registra tu propia tabla de resultados.
• Mide los límites de velocidad y la latencia con un arnés controlado.
• Añade caché y retroceso antes de añadir infraestructura.
• Aprovisiona capacidad RPC dedicada solo donde se requiera acceso en cadena.