Guida all'API di Kalshi: dati di mercato, endpoint storici e order book
L'API ufficiale di Kalshi è una fonte pulita per i dati di scambio correnti. La ricerca sull'esecuzione storica dipende ancora dal fatto che tu abbia conservato l'order book prima che cambiasse.
Un'integrazione dell'API di Kalshi dovrebbe separare lo stato di scambio corrente dal replay storico. Gli endpoint ufficiali espongono mercati, scambi, candele e lo stato dell'order book; la loro documentazione rimane l'autorità per i campi supportati e l'accesso. Quando una strategia deve sapere quale dimensione è stata visualizzata a un prezzo passato, ha bisogno di una serie temporale di scale sì/no registrate piuttosto che solo scambi o candele.
Scegli l'oggetto storico corretto
| Oggetto | Risposte | Impossibile rispondere da solo |
|---|---|---|
| Cronologia degli scambi | Dove sono stati stampati gli scambi corrispondenti | Quale dimensione era in attesa lontano dallo scambio |
| Candele | Movimento di prezzo aggregato in un intervallo | Spread ed esecuzione per un ordine di dimensioni specifiche |
| Order book corrente | Liquidità visualizzata ora | Liquidità visualizzata prima delle ultime modifiche |
| Cronologia dell'order book registrata | Livelli, dimensioni e spread passati | Liquidità nascosta o priorità della coda |
Normalizza sì e no senza perdere la fonte
Kalshi rappresenta i risultati binari come prezzi e dimensioni sì/no. Un caricatore cross-venue può normalizzare questi campi in una struttura bid/ask comune, ma dovrebbe conservare i valori nativi di ticker, lato e fonte in modo che ogni trasformazione possa essere invertita e controllata.
Utilizza la gestione di numeri interi o decimali esatti per le unità di prezzo invece di accumulare deriva in virgola mobile. Registra l'ora di osservazione indipendentemente dai campi di regolamento del mercato; un risultato risolto non deve trapelare in una riga utilizzata da una decisione precedente.
Come DepthFeed registra Kalshi
DepthFeed interroga continuamente gli order book pubblici completi di Kalshi con un ritmo adattivo sotto la quota upstream e memorizza le osservazioni normalizzate con un massimo di 100 livelli per lato. L'intervallo realizzato varia con il carico del mercato attivo, quindi la documentazione del prodotto cattura il metodo piuttosto che promettere un tick artificiale fisso.
Lo stesso schema REST utilizzato per Polymarket trasporta le scale di Kalshi, i timestamp e i metadati del mercato. I ricercatori possono riprodurre una regola nel browser, estrarre una finestra storica tramite l'API o confrontare il risultato con il paper trading live senza scrivere un modello di esecuzione specifico per il venue.
Una sequenza di implementazione sicura
- Leggi la documentazione ufficiale di Kalshi per l'autenticazione corrente, i limiti e i contratti degli endpoint.
- Memorizza i ticker di serie, evento e mercato con l'order book sì/no originale.
- Normalizza i prezzi solo dopo aver preservato la rappresentazione nativa.
- Separa scambi, candele, order book correnti e order book storici registrati nel modello di dati.
- Utilizza le informazioni sull'ora di osservazione solo quando valuti una regola di ingresso.
- Metti alla prova i gap di polling adattivo e le risposte di limitazione della velocità prima della produzione.
Key takeaways
- 01Gli scambi, le candele e gli order book di Kalshi rispondono a diverse domande di ricerca.
- 02Un order book corrente non ricrea l'order book completo in un momento precedente.
- 03La normalizzazione cross-venue dovrebbe preservare i ticker nativi di Kalshi e i valori sì/no.
- 04DepthFeed registra le osservazioni complete dell'order book di Kalshi con un ritmo adattivo documentato.
- 05Un backtest deve mantenere le informazioni di regolamento future fuori dalle decisioni precedenti.
L'API ufficiale di Kalshi è una fonte pulita per i dati di scambio correnti. La ricerca sull'esecuzione storica dipende ancora dal fatto che tu abbia conservato l'order book prima che cambiasse.
Inizia gratis