Données API Kalshi : Marchés, Carnets d'ordres, Chandeliers et Transactions

Une série est une question récurrente (KXBTC15M est Bitcoin toutes les 15 minutes), un événement est une instance de celle-ci, et un marché est un contrat oui/non négociable à l'intérieur de l'événement, avec son strike dans le ticker. GET /series/{series_ticker}, GET /events/{event_ticker} et GET /markets?series_ticker=… les renvoient. Utilisez le ticker de marché complet comme clé de jointure : un ticker d'événement nomme plusieurs marchés avec des prix très différents.

Kalshi documente ses points de terminaison de données de marché comme publics : aucune clé API n'est nécessaire pour séries, événements, marchés, carnet d'ordres, chandeliers ou transactions. L'URL de base de production est https://external-api.kalshi.com/trade-api/v2; l'ancien hôte api.elections.kalshi.com sert les mêmes marchés, pas seulement les élections. Les clés sont nécessaires pour le côté compte (ordres, remplissages, positions) et pour le flux WebSocket.

GET /markets/{ticker}/orderbook retourne deux échelles d’ordres d’achat, oui et non, en prix dollars avec nombre de contrats (orderbook_fp.yes_dollars et no_dollars). Il n’y a pas de tableau ask : un ordre no à p est une offre yes à 1 − p, donc dans l’échantillon enregistré sur cette page le meilleur ordre yes est 0.32, le meilleur ordre no 0.67 et l’ask yes implicite 0.33. La réponse est le carnet actuel ; l’appeler plus tard ne vous dira pas ce qu’il était.

GET /series/{series_ticker}/markets/{ticker}/candlesticks prend start_ts, end_ts et period_interval de 1, 60 ou 1440 minutes. Chaque chandelier porte open, high, low et close pour le bid yes, l’ask yes et le prix échangé, plus volume et open interest. C’est le moyen le moins cher de tracer un marché, mais il enregistre ce qui a été échangé et où le haut du carnet a clôturé, pas la taille disponible.

GET /markets/trades liste les transactions exécutées avec pagination par curseur. Kalshi divise les données en niveaux live et historiques : une fois qu’un marché est réglé avant la coupure publiée à GET /historical/cutoff, lui et ses chandeliers sont servis depuis GET /historical/markets et /historical/markets/{ticker}/candlesticks, et les transactions plus anciennes depuis GET /historical/trades. Lisez la coupure pour chaque type de données avant de supposer qu’un point de terminaison live contient tout.

Les limites de Kalshi sont des budgets de jetons par niveau, avec des compartiments séparés lecture et écriture, plutôt qu’un nombre de requêtes par seconde. Interroger le point de terminaison du carnet d’ordres pour chaque marché ouvert utilise rapidement le budget de lecture. Répondez à un 429 avec un backoff exponentiel, paginez avec le curseur jusqu’à ce qu’il soit vide, et utilisez le WebSocket authentifié quand vous avez besoin de chaque changement de carnet en direct.

Aucun point de terminaison Kalshi ne retourne les échelles oui et non telles qu’elles étaient il y a une heure, une semaine ou un mois. Un backtest qui a besoin de l’écart et de la taille au repos aux temps de décision passés nécessite des carnets enregistrés en direct. DepthFeed a sondé les carnets Kalshi en pleine profondeur depuis janvier 2026 : 1.5 milliard d’instantanés sur plus de 2,600,000 marchés au 21 juin 2026, servis par REST ou sous forme de 197 fichiers Parquet journaliers scellés.