Guía de Trading API de Mercados de Predicción

Resumen de APIs de Mercados de Predicción

Las APIs de mercados de predicción permiten acceso programático a datos de mercado y gestión de órdenes — las mismas capacidades disponibles a través de la interfaz web de cada plataforma, pero accesibles a sistemas de trading automatizado, dashboards personalizados, pipelines de datos y modelos cuantitativos.

Autenticación y Obtención de Claves API

Autenticación API de Kalshi

Kalshi autentica cada solicitud privada con un par de claves asimétricas que usted mismo genera — ningún secreto compartido sale de su máquina. Según la documentación actual de Kalshi (verificada el 24 de septiembre de 2026):

1. Genere un par de claves. Ed25519 es el tipo recomendado (openssl genpkey -algorithm ed25519 -out kalshi.key); RSA-2048 con RSA-PSS/SHA-256 sigue siendo compatible y es lo que usan hoy los SDK oficiales. Mantenga la clave privada segura — controla la entrada de órdenes.
2. Registre la clave pública. En la configuración del perfil (kalshi.com/account/profile) → API Keys → «Create New API Key». Kalshi devuelve un Key ID; la clave privada se queda con usted.
3. Firme cada solicitud. Tres cabeceras: KALSHI-ACCESS-KEY (el Key ID), KALSHI-ACCESS-TIMESTAMP (hora actual en milisegundos) y KALSHI-ACCESS-SIGNATURE — la firma en base64 de la concatenación timestamp + método HTTP + ruta, sin la cadena de consulta (firme /trade-api/v2/portfolio/orders, nunca …?limit=5).
4. Use el host correcto. REST de producción: https://api.elections.kalshi.com/trade-api/v2 (el host más nuevo external-api.kalshi.com sirve la misma API); entorno demo: https://demo-api.kalshi.co/trade-api/v2, con dinero ficticio para probar antes de arriesgar capital real.

import base64, datetime, requests
from cryptography.hazmat.primitives import serialization

with open("kalshi.key", "rb") as f:                      # the private key you generated
    private_key = serialization.load_pem_private_key(f.read(), password=None)

timestamp = str(int(datetime.datetime.now().timestamp() * 1000))
method, path = "GET", "/trade-api/v2/portfolio/balance"   # sign the path WITHOUT any query string
message = (timestamp + method + path).encode("utf-8")
signature = base64.b64encode(private_key.sign(message)).decode("utf-8")   # Ed25519; RSA keys sign with RSA-PSS/SHA-256

headers = {
    "KALSHI-ACCESS-KEY": "YOUR-KEY-ID",
    "KALSHI-ACCESS-TIMESTAMP": timestamp,
    "KALSHI-ACCESS-SIGNATURE": signature,
}
r = requests.get("https://demo-api.kalshi.co" + path, headers=headers)

O deje que firmen los SDK oficiales: pip install kalshi_python_sync (o kalshi_python_async) y npm install kalshi-typescript, publicados cada semana a partir de la especificación OpenAPI de Kalshi.

Autenticación API de Polymarket

El CLOB global de Polymarket es nativo de Ethereum: su billetera es su identidad y las órdenes son mensajes firmados que ejecuta el contrato del exchange en cadena. Los SDK unificados de 2026 ocultan casi todo eso:

1. Lea sin clave. Los datos de mercado (https://gamma-api.polymarket.com para mercados y eventos, https://clob.polymarket.com para libros de órdenes, https://data-api.polymarket.com para posiciones e historial) y el WebSocket de mercado (wss://ws-subscriptions-clob.polymarket.com/ws/market) no requieren credenciales — createPublicClient() en TypeScript, PublicClient() en Python.
2. Opere con un firmante. createSecureClient() (@polymarket/client más viem) o SecureClient.create(private_key=…) (pip install polymarket-client) construyen el firmante a partir de una clave privada; las operaciones de billetera sin gas requieren además una Relayer API key creada en Settings → API Keys en polymarket.com.
3. ¿Migrando? Las bibliotecas antiguas py-clob-client y clob-client quedan sustituidas por los SDK unificados; Polymarket publica una guía de migración.

Autenticación API de Polymarket US

Polymarket US — la sede regulada por la CFTC que opera sobre QCEX y no sobre Polygon — tiene una API convencional aparte en https://api.polymarket.us:

1. Obtenga las claves en el portal de desarrolladores. Con la cuenta de la app aprobada para operar, inicie sesión en polymarket.us/developer con el mismo método que usó en la app y cree una API key: recibirá un Key ID y una Secret Key.
2. Firme como en Kalshi. Tres cabeceras — X-PM-Access-Key, X-PM-Timestamp (milisegundos) y X-PM-Signature, una firma Ed25519 de timestamp + método + ruta hecha con la Secret Key; el timestamp debe estar a menos de 30 segundos de la hora del servidor. Los datos públicos de mercado no requieren clave.
3. O use los SDK. pip install polymarket-us / npm install polymarket-us toman el Key ID y la Secret Key y firman por usted. Las órdenes van a POST /v1/orders (con endpoints de vista previa, cancelación, modificación y cierre de posición) y son de dos tipos: límite y de mercado.

Endpoints de Datos de Mercado

Ambas APIs proporcionan acceso completo a datos de mercado. Los endpoints principales:

• Lista de mercados. Enumerar todos los mercados disponibles con sus especificaciones de contrato, estado (abierto/cerrado/liquidado) y metadatos. Filtrable por categoría, estado y tipo de evento.
• Libro de órdenes. El estado actual del libro de órdenes para un mercado específico — todas las órdenes de compra y venta pendientes, organizadas por nivel de precio.
• Operaciones. Datos históricos de operaciones — cada operación ejecutada con marca de tiempo, precio, cantidad y lado (compra/venta). Esencial para backtesting y análisis de volumen.
• Resumen de mercado / ticker. Estadísticas agregadas del mercado: último precio de operación, volumen de 24 horas, interés abierto, precios altos/bajos.

Para datos en tiempo real, ambas plataformas ofrecen feeds WebSocket que envían actualizaciones del libro de órdenes y operaciones a medida que ocurren, sin la latencia y sobrecarga de límites de tasa de consultar endpoints REST. Cualquier sistema de trading automatizado serio debe usar feeds WebSocket para datos de mercado.

Colocación de Órdenes

Ambas APIs soportan tipos de orden estándar:

• Órdenes límite. Especifique un precio y cantidad. La orden descansa en el libro hasta que se ejecuta por una orden coincidente, usted la cancela o el mercado cierra. Las órdenes límite son órdenes maker y típicamente incurren en comisiones más bajas.
• Órdenes de mercado. Se ejecutan inmediatamente al mejor precio disponible. Las órdenes de mercado son órdenes taker e incurren en comisiones más altas. En mercados con poca liquidez, las órdenes de mercado grandes pueden experimentar deslizamiento.

Parámetros clave para colocación de órdenes en Kalshi:

• ticker — el identificador del mercado (p.ej., "FED-26JUN-T4.50")
• side — "yes" o "no"
• action — "buy" o "sell"
• type — "limit" o "market"
• count — número de contratos
• yes_price o no_price — precio en centavos (1–99 para órdenes límite)

Restricciones importantes: las órdenes no pueden exceder su saldo disponible (no hay trading con margen en mercados de predicción). Kalshi aplica un tamaño máximo de posición por mercado, que varía por contrato.

Gestión de Posiciones y Consultas de Cartera

Gestionar posiciones abiertas programáticamente es esencial para el trading automatizado:

• Posiciones abiertas. Consulte todas sus posiciones actuales en todos los mercados — contrato, lado, cantidad, precio promedio de entrada, precio de mercado actual y P&L no realizado.
• Estado de órdenes. Verifique el estado de órdenes enviadas — pendiente, parcialmente ejecutada, completamente ejecutada o cancelada.
• Saldo y liquidación. Consulte saldo de cuenta, liquidaciones pendientes y disponibilidad de retiro.
• Historial de operaciones. Descargue su historial completo de operaciones para backtesting, análisis de rendimiento y declaración fiscal.

Construyendo un Bot Simple: Monitoreo de Probabilidades del Mercado de IPC

Un punto de partida práctico para el trading API es un bot de monitoreo — un sistema que lee datos de mercado y le alerta sobre cambios significativos, sin colocar operaciones automáticamente:

Este bot de monitoreo no requiere acceso a la API de colocación de órdenes — solo lecturas de datos de mercado. Es una forma de bajo riesgo para familiarizarse con la API y desarrollar la infraestructura para estrategias automatizadas más sofisticadas posteriormente.

Límites de Tasa y Mejores Prácticas

Ambas APIs aplican límites de tasa para prevenir abuso y asegurar la estabilidad de la plataforma:

• API REST de Kalshi: Cubos de tokens, no un tope fijo — cada solicitud cuesta tokens (10 por defecto) y tu nivel fija el presupuesto de recarga por segundo, separado para lecturas y escrituras: Basic 200 / 100, Advanced 300 / 300, Expert 600 / 600, Premier 1.200 / 1.200, Paragon 2.400 / 2.400 (unas 20 lecturas y 10 órdenes por segundo en Basic). Superar el presupuesto devuelve un código 429. Implementa reintentos con retroceso exponencial y jitter.
• WebSocket de Kalshi: Soporta múltiples suscripciones de mercado por conexión. Los mensajes de heartbeat mantienen la conexión. La lógica de reconexión es esencial.
• Polymarket (global): Los límites son escalonados dentro del Builder Program — toda integración nueva empieza en el nivel Standard y los niveles superiores elevan tanto los límites de tasa de la API como los límites diarios de transacciones del relayer; la documentación no publica una cifra fija, así que trate un 429 como la señal y reduzca el ritmo.
• Polymarket US: Un límite global de 20 solicitudes por segundo por API key en los endpoints autenticados y de 20 por segundo por IP en los públicos; superarlo devuelve 429.
• Mejores prácticas generales:
  • Cachear metadatos de mercado localmente y refrescar infrecuentemente (una vez por hora o menos).
  • Usar feeds WebSocket para datos en tiempo real en lugar de consultar endpoints REST.
  • Agrupar operaciones donde sea posible.
  • Implementar circuit breakers que detengan el trading si las tasas de error exceden un umbral.
  • Registrar todas las solicitudes y respuestas API para depuración y auditoría.

Acceso Institucional: Creadores de Mercado, FIX y Conectividad Privada

¿Puede un fondo operar en mercados de predicción a través de la API? En Kalshi, sí — la misma API REST y WebSocket sirve a todos los miembros, y el exchange añade programas institucionales encima:

• Market Maker Program. Los creadores de mercado designados se comprometen a cotizar de forma continua a dos bandas y, a cambio de cumplir requisitos definidos de cotización y volumen, pueden recibir comisiones reducidas y otros beneficios. El estatus se concede tras revisar recursos financieros, experiencia de trading y reputación empresarial, y los beneficios dependen de mantener liquidez y mercados ordenados.
• Liquidity Provider Program. Los proveedores de liquidez designados de una serie se eligen en subastas periódicas en las que los solicitantes indican el incentivo mínimo que aceptarían; cumplir los requisitos del periodo de incentivo otorga la recompensa correspondiente.
• API FIX. Entrada de órdenes por FIX en mm.fix.elections.kalshi.com (puerto 8228 sin retransmisión, 8230 con retransmisión y creación de RFQ), datos de mercado en marketdata.fix.elections.kalshi.com, además de sesiones restringidas de Drop Copy (8229) y Post Trade (8231) gestionadas a través de [email protected].
• Conectividad privada. Los miembros del nivel Premier de la API o superior pueden obtener endpoints de AWS PrivateLink para los hosts de producción REST (external-api.kalshi.com) y WebSocket (external-api-ws.kalshi.com); del nivel Prime en adelante también se puede negociar VPC peering para el tráfico WebSocket.

El equivalente en Polymarket es el Builder Program: los niveles, desde Standard hacia arriba, elevan los límites de tasa de la API y los límites diarios de transacciones del relayer, subvencionan el gas, atribuyen el flujo de órdenes a su perfil de builder y, para los builders que enrutan órdenes, permiten cobrar comisiones. Polymarket US documenta una única API minorista a 20 solicitudes por segundo por clave.

Gestión de Riesgo para Trading Automatizado

Los sistemas de trading automatizado requieren gestión de riesgo rigurosa. Los mercados de predicción tienen características de riesgo únicas:

• Riesgo de resultado binario. Cada posición en el mercado de predicción se resuelve en $1 o $0. No hay pérdida parcial. El dimensionamiento de posiciones debe tener en cuenta esta estructura de pago binaria.
• Concentración de riesgo de eventos. Muchos mercados de predicción se resuelven en la misma fecha. Si tiene posiciones en múltiples contratos del mismo evento, su riesgo está concentrado en un solo momento.
• Límites de pérdida máxima. Defina un límite de pérdida diario y semanal máximo antes de comenzar el trading automatizado. Implemente paradas duras en su código que detengan toda actividad de trading si se alcanza el límite.
• Límites de tamaño de posición. Nunca arriesgue más de un pequeño porcentaje de su capital total en un solo contrato. Una regla común: no más del 2-5% del capital de trading en un solo resultado binario.
• Interruptores del lado del exchange. La API de Kalshi permite colocar órdenes dentro de un grupo de órdenes con un límite de contratos (de 1 a 1.000.000) en una ventana móvil de 15 segundos: cuando el volumen ejecutado del grupo supera el límite, todas las órdenes en reposo del grupo se cancelan automáticamente, y puede disparar la misma cancelación total de forma manual. Úselo como un tope duro que su bot no pueda saltarse.
• Límites de posición regulatorios. Los límites de posición están en el reglamento de cada exchange y en las reglas de cada contrato (el de Kalshi en kalshi.com/regulatory/rulebook), no en un campo de la API — lea las reglas de cualquier mercado en el que piense aumentar el tamaño.
• Manejo de fallos de API. Su sistema debe manejar interrupciones de API, fallos de red y respuestas inesperadas de manera elegante.

Implicaciones Fiscales del Trading de Alta Frecuencia

El trading automatizado genera un alto volumen de eventos tributables. Consideraciones clave:

• Documentación fiscal de Kalshi. Kalshi no emite un 1099 por las ganancias de contratos de eventos. Ofrece un estado mensual de pérdidas y ganancias (Cuenta → Tax Info) y emite el Formulario 1099-INT por intereses y el 1099-MISC por créditos y recompensas por encima de los umbrales del IRS. Cada liquidación de contrato es un evento tributable. Mantenga registros detallados de operaciones desde la API.
• Potencial Sección 1256. Si la Sección 1256 se aplica a los contratos regulados por la CFTC (Kalshi), las ganancias tributan 60% como ganancias de capital a largo plazo / 40% a corto plazo, independientemente del período de tenencia. Si se aplica es una cuestión no resuelta: no se ha verificado que ninguna plataforma trate o informe sus contratos de eventos como contratos de la Sección 1256. Consulte a un profesional fiscal.
• Consideraciones de wash sale. Si opera el mismo contrato frecuentemente, las reglas de wash sale pueden aplicar, rechazando ciertas pérdidas.
• Complejidad fiscal de Polymarket. Operar en la app internacional (CLOB) de Polymarket implica USDC (una criptomoneda), que puede activar eventos separados de ganancias de capital sobre el activo cripto subyacente además de las ganancias o pérdidas en los contratos del mercado de predicción. Las cuentas de Polymarket US se mantienen en dólares estadounidenses, por lo que esta capa no se da allí.