Kalshi API 指南：市場數據、歷史端點和訂單簿
Kalshi 的官方 API 是當前交易所數據的乾淨來源。歷史執行研究仍然取決於您是否保留了在它變更之前的手冊。
DepthFeed··9 min
Kalshi API 整合應將當前交易所狀態與歷史回放分開。官方端點公開市場、交易、K 線圖和訂單簿狀態；其文檔仍然是受支持字段和訪問權限的權威。當策略需要知道過去價格上顯示的大小是多少時，它需要一個是/否階梯的時間序列，而不是僅僅交易或 K 線圖。
選擇正確的歷史對象
| 對象 | 答案 | 無法單獨回答 |
|---|---|---|
| 交易歷史 | 匹配的交易打印的位置 | 交易之外等待的大小是多少 |
| K 線圖 | 一段時間內的彙總價格變動 | 大小訂單的價差和執行情況 |
| 當前訂單簿 | 現在顯示的流動性 | 在最新變更之前的顯示流動性 |
| 記錄的訂單簿歷史記錄 | 過去的級別、大小和價差 | 隱藏的流動性或隊列優先級 |
在不丟失來源的情況下規範化是和否
Kalshi 將二元結果表示為是/否價格和大小。跨交易所加載器可以將這些字段規範化為通用的買/賣結構，但它應保留原始代碼、方向和來源值，以便可以反轉和審計每次轉換。
使用整數或精確的十進制處理價格單位，而不是累積浮點漂移。獨立記錄觀察時間與市場結算字段；已解決的結果不應洩露到早期決策使用的行中。
DepthFeed 如何記錄 Kalshi
DepthFeed 會持續以自適應的步調輪詢 Kalshi 的完整深度公共訂單簿，並在上游配額下存儲規範化的觀察結果，每個方向最多 100 個級別。實現的間隔會根據活動市場的負載而變化，因此產品文檔會捕獲方法，而不是保證人工固定的刻度。
與 Polymarket 相同的 REST 模式承載 Kalshi 階梯、時間戳和市場元數據。研究人員可以在瀏覽器中重播規則，通過 API 提取歷史窗口，或在無需編寫第二個特定場地填充模型的情況下將結果與實時模擬交易進行比較。
安全的實施順序
- 閱讀 Kalshi 的官方文檔，了解當前的身份驗證、限制和端點合約。
- 使用原始的 是/否 訂單簿存儲系列、事件和市場代碼。
- 僅在保留原始表示形式後才規範化價格。
- 在數據模型中分離交易、K 線圖、當前訂單簿和記錄的歷史訂單簿。
- 僅在評估進入規則時使用觀察時間信息。
- 在生產之前，壓力測試自適應輪詢間隙和速率限制響應。
Key takeaways
- 01Kalshi 交易、K 線圖和訂單簿回答不同的研究問題。
- 02當前的訂單簿不會重現早期訂單簿的完整內容。
- 03跨交易所規範化應保留原始 Kalshi 代碼和是/否值。
- 04DepthFeed 記錄具有記錄的自適應步調的 Kalshi 完整深度觀察結果。
- 05回測必須將未來的結算信息排除在早期的決策之外。
Kalshi 的官方 API 是當前交易所數據的乾淨來源。歷史執行研究仍然取決於您是否保留了在它變更之前的手冊。
免費開始