Przewodnik po API Kalshi: Dane rynkowe, punkty końcowe historyczne i księgi zleceń
Oficjalne API Kalshi to czyste źródło aktualnych danych giełdowych. Badania nad historycznymi transakcjami nadal zależą od tego, czy zachowano księgę przed jej zmianą.
Integracja API Kalshi powinna oddzielać aktualny stan giełdy od historycznej powtórki. Oficjalne punkty końcowe udostępniają rynki, transakcje, świece i stan księgi zleceń; ich dokumentacja pozostaje autorytetem dla obsługiwanych pól i dostępu. Gdy strategia musi wiedzieć, jaki rozmiar był wyświetlany po określonej cenie w przeszłości, potrzebuje szeregu czasowego zarejestrowanych drabin tak/nie, a nie tylko transakcji lub świec.
Wybierz odpowiedni obiekt historyczny
| Obiekt | Odpowiedzi | Nie odpowiada samodzielnie |
|---|---|---|
| Historia transakcji | Gdzie drukowano dopasowane transakcje | Jaki rozmiar czekał z dala od transakcji |
| Świece | Agregowany ruch cenowy w określonym interwale | Spread i wykonanie dla zlecenie o określonym rozmiarze |
| Aktualna księga zleceń | Płynność wyświetlana teraz | Płynność wyświetlana przed najnowszymi zmianami |
| Zarejestrowana historia księgi zleceń | Historyczne poziomy, rozmiary i spread | Ukryta płynność lub priorytet kolejki |
Normalizuj tak i nie bez utraty źródła
Kalshi reprezentuje binarne wyniki jako ceny i rozmiary tak/nie. Ładowacz wielo-giełdowy może normalizować te pola do wspólnej struktury bid/ask, ale powinien zachować natywne wartości tickerów, stron i źródła, aby każda transformacja mogła zostać cofnięta i zweryfikowana.
Używaj liczb całkowitych lub dokładnego przetwarzania dziesiętnego dla jednostek ceny zamiast akumulować dryf zmiennoprzecinkowy. Zapisz czas obserwacji niezależnie od pól rozliczeniowych rynku; rozwiązany wynik nie powinien przenikać do wiersza używanego do wcześniejszej decyzji.
Jak DepthFeed rejestruje Kalshi
DepthFeed stale pobiera pełną głębokość publicznych ksiąg Kalshi z adaptacyjnym tempem w ramach upstreamowej limity i przechowuje znormalizowane obserwacje z do 100 poziomów po każdej stronie. Zrealizowany interwał różni się w zależności od obciążenia aktywnego rynku, więc dokumenty produktu rejestrują metodę, a nie obiecują sztuczne stałe ticki.
Ten sam schemat REST używany dla Polymarket zawiera drabiny Kalshi, znaczniki czasu i metadane rynku. Badacze mogą odtworzyć regułę w przeglądarce, pobrać historyczne okno przez API lub porównać wynik z papierowym handlem na żywo bez pisania drugiego modelu wypełniania specyficznego dla giełdy.
Bezpieczna sekwencja implementacji
- Przeczytaj oficjalną dokumentację Kalshi dotyczącą aktualnej autoryzacji, limitów i kontraktów punktów końcowych.
- Przechowuj serie, zdarzenia i tickery rynkowe wraz z księgą tak/nie.
- Normalizuj ceny dopiero po zachowaniu natywnej reprezentacji.
- Oddziel transakcje, świece, aktualne księgi zleceń i zarejestrowane historyczne księgi zleceń w modelu danych.
- Używaj informacji o czasie obserwacji tylko podczas oceny reguły wejścia.
- Przeprowadź testy obciążeniowe luk w adaptacyjnym pobieraniu próbek i odpowiedzi na limity szybkości przed produkcją.
Key takeaways
- 01Transakcje, świece i księgi zleceń Kalshi odpowiadają na różne pytania badawcze.
- 02Aktualna księga zleceń nie odtwarza pełnej księgi zleceń w przeszłości.
- 03Normalizacja wielo-giełdowa powinna zachować natywne tickery Kalshi i wartości tak/nie.
- 04DepthFeed rejestruje pełną głębokość obserwacji Kalshi z udokumentowanym adaptacyjnym tempem.
- 05Backtest musi wykluczyć przyszłe informacje o rozliczeniach z wcześniejszych decyzji.
Oficjalne API Kalshi to czyste źródło aktualnych danych giełdowych. Badania nad historycznymi transakcjami nadal zależą od tego, czy zachowano księgę przed jej zmianą.
Zacznij za darmo