Kalshi scrapen im Jahr 2026 (API & Python)

Kalshi veröffentlicht bereits eine offene, keylose REST-API für seine Marktdaten — Preise, Orderbücher, Trade-Historie, Events und Serien sind allesamt öffentliche Lesezugriffe unter external-api.kalshi.com. Die ehrliche Antwort auf „Wie scrape ich Kalshi" im Jahr 2026 lautet daher: Für die meisten Lesezugriffe rufst du Kalshis eigene API direkt auf. Was weiterhin ein Konto braucht, ist der Handel — das Platzieren von Orders erfordert eine KYC-verifizierte, signierte Session. Dieser Guide behandelt Kalshis offizielle API, warum manuelles Scrapen der Website darüber hinaus unnötig ist, und wann sich eine strukturierte API stattdessen lohnt.

Warum Kalshi-Daten scrapen?

• Event-Wahrscheinlichkeits-Tracking — Kalshis „Yes"-Preis ist eine live, marktimplizierte Wahrscheinlichkeit für reale Ereignisse (Wahlen, Fed-Entscheidungen, Wetter, Sport) und damit nützlich als Prognosesignal.
• Marktstimmungs-Recherche im Vergleich zu klassischen Umfragen — Kalshis implizierte Quoten gegen Umfragen oder Expertenprognosen stellen, um zu sehen, wo Crowds und Meinungsforscher uneinig sind.
• Trading- und Quant-Recherche — Orderbücher, Trade-Prints und historische Candles zum Aufbauen oder Backtesten von Strategien.
• News- und Prognose-Produkte — Widgets zeigen, „was der Markt glaubt, was passiert", neben der Berichterstattung zu einem Ereignis.
• KI-Pipelines — live Event-Wahrscheinlichkeiten in Research-Agenten oder Dashboards einspeisen, die einen numerischen Wert für ungewisse Ausgänge brauchen.

Ist es legal, Kalshi zu scrapen?

Option 1: Kalshis eigene offizielle API (und ihre Grenzen)

Speziell bei Kalshi ist die offizielle API das Erste, worauf man zugreifen sollte — sie ist öffentlich, gut dokumentiert und liefert dieselben Daten, die man sonst scrapen müsste:

curl "https://external-api.kalshi.com/trade-api/v2/markets?limit=10"

Kein x-api-key, kein OAuth, kein Konto für Lesezugriffe nötig. Was sie abdeckt und wo sie trotzdem an Grenzen stößt:

• Lesen ist offen, Schreiben ist gesperrt. Märkte, Events, Serien, Trades und Orderbücher sind öffentlich. Eine Order zu platzieren erfordert ein freigegebenes Konto: RSA-signierte Requests (KALSHI-ACCESS-KEY, -TIMESTAMP, -SIGNATURE) plus KYC, und Kalshi ist nur in einer Teilmenge der US-Bundesstaaten verfügbar.
• Rate Limits skalieren mit der Kontostufe. Öffentlicher/Basic-Zugang nutzt einen Token-Bucket-Limiter (grob 20 Lesezugriffe/Sekunde auf der Einstiegsstufe); höhere Trading-Stufen bekommen größere Budgets. Bei intensivem Polling solltest du trotzdem bei 429-Antworten zurückschalten.
• Die Nutzungsbedingungen schränken die Weiterverwendung ein, nicht den Zugang. Die API selbst hält dich nicht davon ab, viele Daten zu ziehen — die Data Terms of Service begrenzen, was du kommerziell damit bauen darfst (siehe oben).
• Du baust dir dein eigenes Schema zusammen. Märkte, Events, Serien, Orderbücher und historische Candles sind separate Endpoint-Familien mit eigenen Parametern (event_ticker, series_ticker, Cursor, period_interval), die du lernen und paginieren musst.

Option 2: DIY in Python gegen die Website (und warum das unnötig ist)

Weil Kalshis eigene JSON-API offen ist, gibt es kaum einen Grund, die gerenderten Seiten von kalshi.com zu scrapen — du würdest eine React-App nach Zahlen durchsuchen, die dir die API bereits als strukturierte Felder liefert, und dir Markup-Drift einhandeln, das die API nicht hat. Ein minimaler DIY-Pull sieht so aus:

import requests

r = requests.get(
    "https://external-api.kalshi.com/trade-api/v2/markets",
    params={"limit": 10, "status": "active"},
).json()
markets = r["markets"]

Das funktioniert einwandfrei für ein einzelnes Skript. Die Kompromisse zeigen sich, sobald du mehrere Plattformen ziehst:

• Kalshis Schema ist Kalshis eigenes. Feldnamen, Ticker-Formate und Paginierungs-Cursor sind spezifisch für diese API — eine eigene Integration, die gepflegt werden muss, wenn Kalshi eine von mehreren Plattformen ist, die du trackst.
• Keine einheitliche Auth oder Normalisierung über Quellen hinweg. Wenn du zusätzlich Polymarket, Metaculus oder klassische Marktdaten ziehst, hat jede Quelle ihren eigenen Client, ihr eigenes Schema und eigenes Rate-Limit-Verhalten, die du zusammenführen musst.
• Polling und Speicherung bleiben deine Aufgabe. Kalshi wiederholt, dedupliziert oder stempelt deine Pulls nicht für dich — das liegt so oder so bei deinem Code.

Option 3: Eine strukturierte Kalshi-API

Der Mehrwert einer Kalshi scraping API liegt nicht darin, Daten freizuschalten, die Kalshi versteckt — sondern in einem normalisierten Schema und einem einzigen x-api-key über Kalshi und jede andere Plattform im Katalog hinweg, sodass du nicht pro Quelle einen eigenen Client pflegen musst. Aktive Märkte auflisten:

curl "https://api.crawlora.net/api/v1/kalshi/markets?limit=10&status=active" \
  -H "x-api-key: $CRAWLORA_API_KEY"

Märkte, Events und Historie in Python:

import requests
h = {"x-api-key": "YOUR_API_KEY"}
base = "https://api.crawlora.net/api/v1/kalshi"

markets = requests.get(f"{base}/markets", headers=h,
                        params={"limit": 10, "status": "active"}).json()["data"]
market = requests.get(f"{base}/market/KXELONMARS-99", headers=h).json()["data"]
events = requests.get(f"{base}/events", headers=h, params={"limit": 10}).json()["data"]

Eine Marktdetail-Antwort ist normalisiertes JSON, das du direkt speichern kannst (echte Felder):

{
  "code": 200,
  "msg": "OK",
  "data": {
    "market": {
      "ticker": "KXELONMARS-99",
      "event_ticker": "KXELONMARS-99",
      "title": "Will Elon Musk visit Mars before Aug 1, 2099?",
      "status": "active",
      "last_price": 0.08,
      "yes_bid": 0.08,
      "yes_ask": 0.1,
      "volume": 94840.88
    },
    "source_url": "https://external-api.kalshi.com/trade-api/v2/markets/KXELONMARS-99",
    "fetched_at": "2026-06-07T14:00:00Z"
  }
}

Orderbücher und Preishistorie hinter demselben Key:

book = requests.get(f"{base}/market/KXELONMARS-99/orderbook", headers=h).json()["data"]
history = requests.get(f"{base}/market/KXELONMARS-99/history", headers=h,
                        params={"period_interval": 1440}).json()["data"]
trades = requests.get(f"{base}/trades", headers=h, params={"ticker": "KXELONMARS-99"}).json()["data"]
event = requests.get(f"{base}/event/KXELONMARS-99", headers=h).json()["data"]
series = requests.get(f"{base}/series/KXELONMARS", headers=h).json()["data"]

Märkte werden über ticker angesprochen (z. B. KXELONMARS-99), Events über event_ticker und Serien über series_ticker — eine Serie ist ein wiederkehrendes Thema (etwa eine wöchentliche Wirtschaftsdaten-Veröffentlichung), Events sind konkrete Instanzen darunter, und Märkte sind die einzelnen Yes/No-Kontrakte innerhalb eines Events. Jede Antwort enthält source_url und fetched_at, also speicher den Zeitstempel bei jeder Zeile mit und zieh die Daten nach Zeitplan erneut.

Was du sammeln kannst

• Märkte — Ticker, Status, letzter Preis, Yes/No-Bid-Ask und Volumen, gelistet oder per Ticker.
• Orderbücher — live Yes/No-Preisstufen und -Größen für einen Markt.
• Preishistorie — OHLC-Candlesticks pro Markt oder über mehrere Ticker gleichzeitig, inklusive Open Interest.
• Trades — einzelne Fills mit Preis, Seite und Anzahl, für einen Markt oder über die gesamte Börse.
• Events und Serien — Event-Metadaten, Abrechnungsquellen, gruppierte Märkte sowie Kategorie/Häufigkeit auf Serienebene.
• Börsenstatus und Zeitplan — ob gerade gehandelt wird und die Handelszeiten der Börse.
• Historische/abgerechnete Daten — finalisierte Märkte und Trades jenseits von Kalshis Live-Cutoff.

Grenzen

• Die Data Terms of Service, nicht die API, sind das eigentliche Nadelöhr. Lesezugriffe sind offen, aber Weiterverbreitung, Archivierung für andere oder ML-/KI-Training mit Kalshi-Daten braucht vorherige schriftliche Zustimmung — prüf die Bedingungen, bevor du ein kommerzielles Produkt darauf baust.
• Prognosemarkt-Preise, keine Gewissheiten. Ein „Yes"-Preis ist die implizierte Wahrscheinlichkeit des Marktes, keine Garantie für den Ausgang — behandle ihn als Signal, nicht als Prognose.
• US-reguliert, US-fokussierte Märkte. Kalshi ist eine von der CFTC regulierte DCM, für den Handel in einer Teilmenge der US-Bundesstaaten verfügbar; die Marktdaten spiegeln diesen Umfang.
• Historische Daten haben einen Cutoff. Kalshi trennt Live-/aktive Daten von einem historical/-Set mit eigenem cutoff-Endpunkt — prüf, welches Zeitfenster du abfragst.
• Keine Anlageberatung. Speicher fetched_at bei jedem Pull und behandle Werte als Recherche-Input, nicht als Trading-Signale.

Wo das eingesetzt wird

• Prognose- und Wahrscheinlichkeits-Dashboards — verfolgen, wie sich Kalshis implizierte Quoten für ein Ereignis über die Zeit bewegen.
• Stimmungsvergleich — Kalshi-Preise neben Umfragen, Expertenprognosen oder Berichterstattung zum selben Ereignis stellen.
• Quant- und Research-Pipelines — Orderbücher und Trade-Historie für Strategie-Recherche (vorbehaltlich Kalshis Nutzungsbedingungen).
• KI-Agenten und Research-Tools — ein numerischer Wahrscheinlichkeitswert für reale Ereignisse als Input für nachgelagerte Auswertungen.

Sources

Loslegen mit dem Sammeln

Probier es erst kostenlos aus: Jag eine beliebige öffentliche URL durch den Free Web Scraper oder prüf mit dem Anti-Bot Checker, ob eine Seite Bots blockiert — ohne Anmeldung.

Teste den Markets-Endpoint im Playground, prüf das Schema in den API docs und schau dir das pricing an. Kalshi ist ein Blick auf marktimplizierte Wahrscheinlichkeit; für die Seite der klassischen Märkte deckt how to scrape Yahoo Finance Aktien ab, und how to scrape CoinGecko deckt Krypto ab — nützlich, um das mit ereignisgetriebenen Bewegungen zu vergleichen. Für die rechtlichen Grundlagen dazu siehe is web scraping legal.