[ blog · comparison ]11 min read

API de Polymarket vs Kalshi: guía lado a lado para desarrolladores (auth, CLOB, WebSocket, datos históricos)

Sarah Choy·Publicado el 3 de mayo de 2026·11 min de lectura

Polymarket y Kalshi ejecutan la misma primitiva — contratos sí/no sobre un CLOB — a través de APIs completamente distintas. Una exige firmas EIP-712 y una wallet de Polygon; la otra es un endpoint REST con FIX opcional. Si estás construyendo un agente de pronóstico, un bot de arbitraje o un monitor de smart money, aquí está la guía lado a lado que ya debería existir.

Resumen

• •Polymarket usa órdenes firmadas con EIP-712 enviadas a su CLOB en Polygon — aplican el onboarding de wallet y las comisiones de gas.
• •Kalshi usa auth estándar REST + WebSocket (email/contraseña → token), más una pasarela FIX opcional para usuarios institucionales.
• •Ambos exponen libro de órdenes, operaciones y datos históricos, pero el esquema y la semántica de resolución difieren lo suficiente como para que las bibliotecas 'unificadas' sean el tema de Show HN más solicitado en este rincón del tooling cripto/cuant.
• •El arbitraje entre sitios sobre contratos equivalentes es el patrón de construcción más común (más de 10 bots de código abierto en GitHub).
• •API Pick Prediction Markets Search envuelve ambos sitios en un único endpoint POST para el descubrimiento de contratos en lenguaje natural — 50 créditos por llamada, resultados semánticos rankeados.

Por qué existe este artículo

Si has pasado algo de tiempo construyendo sobre mercados de predicción, conoces la petición canónica: 'quiero consultar Polymarket y Kalshi desde el mismo script de Python y recuperar una lista limpia de contratos coincidentes.' El hilo de comentarios de HN en cada Show HN de mercados de predicción converge inevitablemente en esto — hay un patrón recurrente de publicaciones de "CCXT para mercados de predicción", lo que indica que la demanda existe y que las soluciones actuales no dan del todo en el clavo.

La dificultad es real. Los dos sitios resuelven la misma primitiva — contratos binarios "sí/no" sobre un libro de órdenes de límite central — pero los exponen a través de APIs dramáticamente distintas. Aquí tienes una visión funcional de desarrollador de ambos, lado a lado, con el código que realmente necesitas.

Dos sitios, dos arquitecturas

Polymarket

• Cadena: Polygon (liquidaciones en USDC.e)
• Auth: firma de datos tipados EIP-712 con la clave privada de una wallet; sin token bearer tradicional
• Colocación de órdenes: orden firmada enviada a la API CLOB; el gas lo paga Polymarket vía meta-transacciones
• Descubrimiento de mercados: la API Gamma (REST + JSON) para explorar mercados activos, más una API CLOB separada para el libro de órdenes en vivo
• Datos en tiempo real: stream WebSocket para actualizaciones del libro de órdenes y operaciones
• Datos históricos: endpoints REST para operaciones; snapshots diarios descargables aparte

Kalshi

• Liquidación: USD vía ACH y transferencia (banco de EE. UU. requerido)
• Auth: email + contraseña → token bearer, O clave de API (institucional)
• Colocación de órdenes: POST REST autenticado estándar a /portfolio/orders
• Descubrimiento de mercados: endpoints REST para eventos, mercados y series; esquema limpio
• Datos en tiempo real: WebSocket y FIX (institucional) para ejecuciones, libro de órdenes, ticker
• Datos históricos: endpoints REST para operaciones; datos de resolución y liquidación de mercados sencillos

Lado a lado

Código funcional: hola-mundo en cada uno

Polymarket: listar mercados activos

import requests

# Gamma API — no auth required for browsing
r = requests.get(
    "https://gamma-api.polymarket.com/markets",
    params={"active": "true", "limit": 25, "order": "volume"},
)
markets = r.json()
for m in markets[:5]:
    print(m["question"], "→", m["outcomePrices"])

Polymarket: colocar una orden firmada (esbozo)

# Full order placement requires py-order-utils + a Polygon wallet
# This is the structural sketch — not runnable without wallet setup
from py_order_utils.builders import OrderBuilder
from py_order_utils.signer import Signer

signer = Signer(private_key="0xYOUR_PRIVATE_KEY")
builder = OrderBuilder(
    exchange_address="0x...",
    chain_id=137,
    signer=signer,
)

order = builder.build_signed_order({
    "maker": signer.address(),
    "tokenId": "...",        # the yes/no token ID for the market
    "makerAmount": "1000000", # USDC.e in atomic units
    "takerAmount": "1500000",
    "side": "BUY",
    "feeRateBps": 0,
    "nonce": 0,
    "expiration": 0,         # 0 = no expiry
})

requests.post(
    "https://clob.polymarket.com/order",
    json={"order": order, "owner": signer.address(), "orderType": "GTC"},
)

Kalshi: iniciar sesión y colocar una orden de límite

import requests

# Step 1 — login
r = requests.post(
    "https://api.elections.kalshi.com/trade-api/v2/login",
    json={"email": "you@example.com", "password": "..."},
).json()
token = r["token"]
headers = {"Authorization": f"Bearer {token}"}

# Step 2 — list markets in an event
r = requests.get(
    "https://api.elections.kalshi.com/trade-api/v2/markets",
    params={"event_ticker": "POTUS-2028", "limit": 25},
    headers=headers,
).json()
print(r["markets"][:5])

# Step 3 — place a limit buy on the "Yes" side at 60 cents
r = requests.post(
    "https://api.elections.kalshi.com/trade-api/v2/portfolio/orders",
    headers=headers,
    json={
        "ticker": "POTUS-2028-DEM",
        "type": "limit",
        "action": "buy",
        "side": "yes",
        "count": 100,            # 100 contracts
        "yes_price": 60,         # 60 cents
        "client_order_id": "abc123",
    },
)
print(r.json())

API Pick: descubrimiento en lenguaje natural a través de ambos

import requests

r = requests.post(
    "https://www.apipick.com/api/search/prediction-markets",
    headers={"x-api-key": "pk_yourkey"},
    json={"query": "Federal Reserve rate cuts before end of 2026"},
)
for hit in r.json()["results"][:5]:
    print(hit["title"], "@", hit["venue"], "→", hit["url"])

# Returns ranked matches across Polymarket + Kalshi.
# 50 credits per call (~$0.05), only on HTTP 200.

Tres patrones de producción que realmente funcionan

1. El bot de arbitraje entre sitios

El patrón más común en GitHub: una lista blanca curada de "este contrato de Polymarket resuelve sobre el mismo desenlace que este contrato de Kalshi". El bot vigila ambos libros, calcula la probabilidad implícita y toma una posición cuando el diferencial cruza un umbral. Ejemplos: ImMike/polymarket-arbitrage y realfishsam/prediction-market-arbitrage-bot.

La parte difícil es la lista blanca. "¿Recortará la Fed 25 pb en la reunión de diciembre?" parece lo mismo para un humano, pero las fuentes de resolución y la redacción exacta difieren; un emparejador automático se equivoca con frecuencia suficiente como para que los bots reales usen mapeos curados por humanos.

2. El monitor de smart money

Las ballenas en Polymarket son visibles on-chain. Un monitor vigila Polygon en busca de gran flujo de órdenes en mercados específicos, saca a la luz posiciones grandes y marca movimientos rápidos de precio antes de que los titulares lleguen a las APIs de noticias. Empareja con News Search para confirmar si un movimiento aparente está impulsado por noticias o es pura especulación.

3. El feed de pronósticos para un agente LLM

Traer los precios actuales de Polymarket / Kalshi al contexto de un agente LLM permite al modelo dar respuestas fundamentadas en probabilidad: "los mercados de apuestas actuales implican una probabilidad de ~65% de X". Este es el caso de uso de descubrimiento que cubre API Pick — dada una pregunta en lenguaje natural del agente, devuelve contratos rankeados para que el agente pueda citar el precio en su respuesta.

Trampas comunes (recopiladas de los comentarios de HN)

• Firma EIP-712 de Polymarket — la firma de la orden es determinista, pero los errores de tooling son comunes. Usa py-order-utils en lugar de hacer la tuya propia. La mayoría de las pérdidas tempranas de bots vienen de desajustes de firma que la API rechaza en silencio.
• Límites de tasa de Kalshi — documentados en 100 req/seg pero menores en algunos endpoints durante los días de eventos concurridos (noches electorales, FOMC). Construye reintento con backoff en tu cliente.
• Picos de gas de Polymarket — el gas de Polygon puede dispararse en días de gran volumen. Polymarket subvenciona la mayoría de la colocación de órdenes vía meta-transacciones, pero la liquidación y la retirada las paga el usuario. Tenlo en cuenta en los cálculos de P&L.
• Desajustes de liquidación — los equivalentes aparentes a veces resuelven de forma distinta. Lee siempre las cláusulas de fuente de resolución de ambos contratos antes de operar en pares.
• Desconexiones de WebSocket — ambos sitios tienen cortes rutinarios de WebSocket. La lógica de reconexión con repetición por número de secuencia es innegociable para cualquier bot en producción.

Elegir rápido

Hacia dónde se dirige esto

Los mercados de predicción están recibiendo una cantidad inusual de atención mainstream ahora mismo: mayores volúmenes en torno a las elecciones de EE. UU., los eventos del FOMC, los deportes y las preguntas de despegue de la IA; integraciones más amplias con sitios de noticias que muestran probabilidades implícitas; y una ola de tooling para desarrolladores (Show HNs, repos de GitHub) que converge en el mismo tema — 'alguien debería escribir CCXT para mercados de predicción.'

No creemos que una biblioteca de ejecución unificada al estilo CCXT sea la forma correcta. Las diferencias en auth, liquidación y régimen regulatorio son demasiado profundas para abstraerlas con limpieza sin mentirle al usuario. Pero el problema de descubrimiento — dada una pregunta en lenguaje natural, encontrar los contratos que ya existen — sí es resoluble con búsqueda semántica, y eso es lo que hace API Pick Prediction Markets Search. Encuentra el contrato; coloca la orden en el sitio.

Escrito por

Sarah Choy

CEO, API Pick

Sarah Choy es la CEO de API Pick. Escribe sobre cómo construir APIs listas para producción para agentes de IA y flujos de trabajo con LLMs.