Datos Kalshi: libros de órdenes en vivo, API y las cuatro capas de datos

Kalshi nombra todo con tres tickers anidados: una serie (KXBTC15M, cada mercado de Bitcoin de 15 minutos), un evento (una ventana de esa serie) y un mercado (un strike dentro del evento, como KXBTC15M-26JUN211530-30). El ticker del mercado es la clave de unión; los tickers de serie y evento son cómo descubres mercados en bloque. Equivocarse en este nivel es el error de conciliación más común, porque un evento contiene varios mercados con strikes diferentes y libros muy distintos.

La API de Kalshi sirve velas: apertura, máximo, mínimo y cierre del precio sí durante períodos fijos, con volumen. Para precisión de pronóstico, calibración y gráficos, esa es la entrada correcta. Lo que una vela no puede decir es si había tamaño disponible: un cierre de 32 centavos significa que se imprimió una operación allí, no que una orden de 500 contratos podría haberse llenado cerca. En un mercado de 15 minutos, una serie de velas gruesa también lleva solo unos pocos puntos durante toda la vida del contrato.

El endpoint de operaciones de Kalshi devuelve ejecuciones con precio, cantidad y lado taker, y su nivel histórico las conserva. Eso cubre investigación de volumen, flujo y tiempo de ejecución. Como con cualquier cinta de operaciones, no puede recuperar el libro: un mercado delgado y uno profundo pueden imprimir las mismas operaciones, por lo que el deslizamiento que pagaría una orden no se deriva solo de las operaciones.

Un libro de Kalshi son dos escaleras de ofertas: ofertas de sí y ofertas de no. No hay un lado de demanda separado, porque una oferta de no a precio p es una oferta de sí a 1 − p. En la muestra registrada a continuación, la mejor oferta de sí es 0.32 y la mejor oferta de no es 0.67, por lo que la demanda implícita de sí es 0.33 — un mercado de un centavo. El punto final público del libro de pedidos de Kalshi devuelve esta estructura solo para el momento presente; su nivel histórico cubre operaciones y velas, no profundidad a lo largo del tiempo. Reproducir el libro tal como estaba requiere una captura continua, que es el archivo de DepthFeed.

DepthFeed ofrece las capas grabadas sobre una superficie REST. El descubrimiento de mercado toma un ticker de serie y un rango de tiempo y devuelve los mercados con sus tickers y metadatos; la ruta snapshot devuelve libros grabados para un ticker de mercado exacto, con include_orderbook exponiendo ambas escaleras; orderbook/latest devuelve el libro grabado más reciente. El downsampling selecciona una observación grabada real en lugar de interpolar una, para que un hueco siga siendo un hueco visible.

Usa CSV para inspección y pequeños extractos, Parquet para investigación columnar grande, y REST para extracciones acotadas o incrementales. El formato debe cambiar cómo llegan los bytes, nunca qué significa un registro: conserva el ticker de mercado, la marca de tiempo de recepción en milisegundos, los arreglos completos de precio y tamaño para sí y no, y marcadores explícitos donde faltan datos. Un conjunto de datos Kalshi reducido a un precio por fila es una serie de velas bajo otro nombre.

El archivo grabado comienza en enero 2026, donde comenzó la captura continua, no donde empezó Kalshi — las propias velas y operaciones de Kalshi llegan más atrás que cualquier archivo de libro de terceros, por eso las capas son complementos y no sustitutos. La cobertura aquí es mercados cripto; las cifras describen muestras medidas en una cohorte nombrada, no una garantía de servicio. Donde un mercado no fue capturado, la respuesta es un hueco explícito.