Kalshi API 指南：市场数据、历史端点和订单簿
Kalshi 的官方 API 是当前交易所数据的干净来源。历史执行研究仍然取决于您是否保留了在它改变之前的订单簿。
DepthFeed··9 min
Kalshi API 集成应将当前的交易所状态与历史回放分开。官方端点公开市场、交易、K 线图和订单簿状态；它们的文档仍然是支持的字段和访问权限的权威。当策略需要知道过去价格上显示的规模时，它需要一个记录的 yes/no 阶梯的时间序列，而不是仅交易或 K 线图。
选择正确的历史对象
| 对象 | 答案 | 无法单独回答 |
|---|---|---|
| 交易历史 | 已匹配的交易记录的位置 | 交易之外等待的规模 |
| K 线图 | 一段时间内汇总的价格变动 | 大小订单的价差和执行 |
| 当前订单簿 | 当前显示的流动性 | 在最新变化之前的显示的流动性 |
| 记录的订单簿历史 | 过去的级别、规模和价差 | 隐藏的流动性或队列优先级 |
在不丢失来源的情况下规范化 yes 和 no
Kalshi 将二元结果表示为 yes/no 价格和规模。跨交易所的加载器可以将这些字段规范化为通用的买/卖结构，但它应保留原始的 ticker、方向和来源值，以便可以反转和审计每次转换。
使用整数或精确的十进制处理价格单位，而不是累积浮点数漂移。独立于市场结算字段记录观察时间；已解决的结果不应泄露到早期决策使用的行中。
DepthFeed 如何记录 Kalshi
DepthFeed 持续以自适应的步调轮询 Kalshi 的完整深度公共订单簿，低于上游配额，并存储规范化的观察结果，每侧最多 100 个级别。实际间隔随活跃市场负载而变化，因此产品文档会捕获方法而不是承诺人为固定的 tick。
用于 Polymarket 的相同 REST 模式承载 Kalshi 阶梯、时间戳和市场元数据。研究人员可以在浏览器中重放规则，通过 API 提取历史窗口，或在无需编写第二个特定于场地的填充模型的情况下将结果与实时模拟交易进行比较。
一个安全的实现序列
- 阅读 Kalshi 的官方文档，了解当前的身份验证、限制和端点合同。
- 使用原始的 yes/no 订单簿存储系列、事件和市场 ticker。
- 仅在保留原始表示形式后才规范化价格。
- 在数据模型中分离交易、K 线图、当前订单簿和记录的历史订单簿。
- 仅在评估进入规则时使用观察时间信息。
- 在生产之前，压力测试自适应轮询间隔和速率限制响应。
Key takeaways
- 01Kalshi 交易、K 线图和订单簿回答不同的研究问题。
- 02当前的订单簿不会重现早期时间的完整订单簿。
- 03跨交易所规范化应保留原始的 Kalshi ticker 和 yes/no 值。
- 04DepthFeed 记录具有文档化的自适应步调的完整深度 Kalshi 观察结果。
- 05回测必须将未来的结算信息排除在早期的决策之外。
Kalshi 的官方 API 是当前交易所数据的干净来源。历史执行研究仍然取决于您是否保留了在它改变之前的订单簿。
免费开始