API de Kalshi: datos públicos, flujos o acceso a la cuenta

Por PredictionToolkit · Publicado el 2026-11-03

Un navegador de mercados y un motor de órdenes no necesitan el mismo acceso. Define primero los datos y las acciones y después elige la API nativa de Kalshi o una capa compatible con las credenciales, el entorno y el modelo operativo adecuados.

Elige la API de contratos de eventos

La documentación de Kalshi separa las API Predictions para contratos de eventos de las API Perps para futuros perpetuos. Para mercados de predicción, empieza por Predictions. La guía REST pública obtiene series, eventos, mercados y libros sin autenticación; no establece acceso anónimo a datos de cuenta ni al envío de órdenes.

Ajusta las credenciales a la interfaz

• Consultas REST de mercados públicos: utiliza los endpoints documentados para descubrimiento e instantáneas del libro.
• WebSocket: autentica la conexión inicial incluso al suscribirte a canales de datos públicos; esos canales no añaden otra comprobación de autorización por canal.
• Operaciones de cuenta y negociación: utiliza las solicitudes firmadas exigidas y las capacidades permitidas de la cuenta.

La guía actual de claves admite Ed25519 y RSA-PSS. Elige un tipo compatible con la versión real del cliente, en lugar de copiar un ejemplo antiguo que solo admite RSA. El identificador de clave señala la clave registrada; la clave privada firma solicitudes. Mantén la clave privada fuera del código enviado al navegador, los repositorios públicos y los registros, y consulta la guía oficial para firmar el método y la ruta exactos.

Separa demo y producción

Los hosts REST recomendados son external-api.kalshi.com para producción y external-api.demo.kalshi.co para demo, con /trade-api/v2 como ruta base. Las claves de demo y producción no son intercambiables. Empieza el desarrollo que dependa de una cuenta en demo y comprueba explícitamente el entorno antes de activar una acción de producción. Un resultado de demo no valida liquidez ni ejecución reales.

¿Cliente directo, capa local o servicio alojado?

La integración directa mantiene visibles los identificadores y contratos de API propios de Kalshi. PMXT ofrece una interfaz SDK común cuando la plataforma implementa la capacidad. En modo autoalojado, pmxt-core local se conecta a la plataforma y usa sus credenciales nativas cuando hacen falta. PMXT alojado utiliza su propia clave e infraestructura; las operaciones de escritura alojadas documentadas emplean custodia PreFundedEscrow. Compara la compatibilidad de métodos y la custodia del modo elegido, no solo los nombres de funciones del SDK.

Construye primero un flujo de datos acotado

• Identifica la serie, el evento y el ticker del mercado y conserva las reglas exactas. El nombre de un evento no identifica un mercado ejecutable.
• Consulta una muestra pequeña de mercados y libros y conserva tiempos, unidades de precio y cantidad disponible antes de crear un gráfico o una comparación.
• En los flujos, gestiona la pérdida de conexión y la recuperación del estado; una conexión abierta no demuestra por sí sola datos actuales utilizables.
• Comprueba los límites y costes de endpoints actuales de la cuenta y aplica espera progresiva ante respuestas HTTP 429.
• Revisa permisos y semántica de órdenes por separado de una consulta pública satisfactoria.

Separa capacidad y dinero en el presupuesto

Kalshi documenta presupuestos de solicitudes basados en tokens, con presupuestos de lectura y escritura separados. Aquí los tokens miden capacidad API; una cifra de solicitudes por segundo de un ejemplo antiguo no es un cupo universal. Consulta costes y niveles actuales. El plan de un proveedor alojado, tu infraestructura y las comisiones de negociación son categorías de coste distintas.

Las fuentes siguientes se revisaron para las decisiones de acceso de esta guía. No se creó una clave, conectó una cuenta ni envió una orden. Utiliza los perfiles enlazados para comparar interfaces y las referencias oficiales para confirmar el endpoint y los permisos exactos antes de implementar.