Données Kalshi : Carnets d'ordres live, API et les quatre couches de données

Kalshi nomme tout avec trois tickers imbriqués : une série (KXBTC15M, chaque marché Bitcoin de 15 minutes), un événement (une fenêtre de cette série) et un marché (un strike dans l’événement, tel que KXBTC15M-26JUN211530-30). Le ticker du marché est la clé de jointure ; les tickers de série et d’événement sont comment découvrir les marchés en masse. Se tromper à ce niveau est le bug de réconciliation le plus courant, car un événement contient plusieurs marchés avec des strikes différents et des carnets très différents.

L’API de Kalshi sert des chandeliers : ouverture, haut, bas et clôture du prix oui sur des périodes fixes, avec volume. Pour la précision des prévisions, la calibration et le charting, c’est la bonne entrée. Ce qu’un chandelier ne peut pas dire est si la taille était disponible : une clôture à 32 cents signifie qu’une transaction a été imprimée là, pas qu’un ordre de 500 contrats aurait pu se remplir près de là. Sur un marché 15 minutes, une série de chandeliers grossière ne porte aussi que quelques points sur toute la vie du contrat.

Le point de terminaison des transactions Kalshi retourne les remplissages exécutés avec prix, quantité et côté preneur, et son niveau historique les conserve. Cela couvre la recherche sur volume, flux et timing des remplissages. Comme pour toute bande de transactions, il ne peut pas reconstituer le carnet : un marché mince et un marché profond peuvent imprimer les mêmes transactions, donc le slippage qu’un ordre aurait payé n’est pas dérivable des seules transactions.

Un carnet Kalshi est constitué de deux échelles d'offres : offres oui et offres non. Il n'y a pas de côté demande séparé, car une offre non au prix p est une offre oui au prix 1 − p. Dans l'échantillon enregistré ci-dessous, la meilleure offre oui est 0.32 et la meilleure offre non est 0.67, donc la demande implicite oui est 0.33 — un marché à un centime. Le point de terminaison public du carnet d'ordres de Kalshi renvoie cette structure pour le moment présent uniquement ; son niveau historique couvre les transactions et les chandeliers, pas la profondeur au fil du temps. Rejouer le carnet tel qu'il était nécessite une capture continue, ce que l'archive de DepthFeed fournit.

DepthFeed sert les couches enregistrées via une surface REST unique. La découverte de marché prend un ticker de série et une plage temporelle et retourne les marchés avec leurs tickers et métadonnées ; la route snapshot retourne les carnets enregistrés pour un ticker de marché exact, avec include_orderbook exposant les deux ladders ; orderbook/latest retourne le carnet enregistré le plus récent. Le downsampling sélectionne une observation réelle enregistrée plutôt que d’en interpoler une, ainsi un trou reste un trou visible.

Utilisez CSV pour l'inspection et les petits extraits, Parquet pour la recherche colonnaire volumineuse, et REST pour des extractions bornées ou incrémentales. Le format doit changer la manière dont les octets arrivent, jamais la signification d'un enregistrement : conservez le ticker du marché, le timestamp de réception en millisecondes, les tableaux complets de prix et tailles oui et non, et les marqueurs explicites là où les données sont absentes. Un ensemble de données Kalshi réduit à un prix par ligne est une série de chandeliers sous un autre nom.

L’archive enregistrée commence en janvier 2026, où la capture continue a débuté, pas là où Kalshi a commencé — les chandeliers et transactions propres à Kalshi remontent plus loin que toute archive tierce de carnet, c’est pourquoi les couches sont complémentaires et non substituables. La couverture ici concerne les marchés crypto ; les chiffres décrivent des échantillons mesurés sur une cohorte nommée, pas une garantie de service. Lorsqu’un marché n’a pas été capturé, la réponse est un vide explicite.