最佳预测市场数据 API:在构建之前需要比较的内容
最佳 API 并非拥有最长端点列表的 API。 而是历史、时间戳、盘口深度和交付模型与系统需要复现的决策相匹配的 API。
预测市场数据 API 应该在六个方面进行比较:场馆覆盖范围、实时交付、历史订单簿深度、时间戳质量、结算字段和可用的导出格式。 官方 API 通常是当前市场和交易的事实依据,而当回测必须重建过去存在的价差、静止大小和滑点时,则需要持续记录的第三方存档。
重要的比较
| 要求 | 最低可用证据 | 重要原因 |
|---|---|---|
| 实时研究 | 当前市场、交易和完整盘口更新 | 仅中间价隐藏了价差和可用大小 |
| 回测 | 带有时间戳的历史买/卖盘 | 价格序列无法复现深度感知的成交 |
| 跨场馆工作 | 一个文档化的标准化模式 | Polymarket 和 Kalshi 暴露了不同的原生盘口形状 |
| 可审计性 | 源和接收时间戳以及缺失数据规则 | 延迟和差距必须保持可衡量 |
| 批量分析 | REST 分页和 CSV 或 Parquet 导出 | 大型研究不应依赖于每行一个请求 |
| 生产使用 | 已发布的限制、身份验证和重试行为 | 原型端点不是运行合同 |
官方 API 与记录存档
Polymarket 和 Kalshi 发布了自己的开发者界面,这些官方接口应始终作为当前市场定义、场馆规则和支持的交易流程的参考。 当应用程序需要场馆的当前状态时,它们是正确的起点。
历史深度是一种不同的产品。 完整的订单簿是瞬变的:一旦级别发生变化,后来的价格历史点就无法揭示消失的大小、支付的价差或订单的价格影响。 声称具有逼真回放功能的提供商应展示它如何捕获、标准化和保留这些盘口。
DepthFeed 如何适应比较
DepthFeed 专为 Polymarket 和 Kalshi 的研究而构建。 它提供记录的完整深度盘口、标准化的时间戳、基础参考字段和感知结算的市场记录,通过 REST 提供,并具有用于当前盘口的实时 WebSocket 通道。 浏览器 Backtest Lab 和 API 使用相同的模式。
该产品不会将缺失的观察值转换为合成填充。 覆盖范围保持缺失,场馆特定的捕获记录在案,研究人员可以在发送到模拟交易之前,在中间价、固定滑点和深度感知的 VWAP 假设下测试规则。
实用的选择流程
- 写下应用程序是否需要当前状态、历史回放或两者。
- 在比较价格之前,请求一个包含买单、卖单、大小和时间戳的真实市场样本。
- 验证每个场馆可用的最早日期和缺失数据策略。
- 在仅比较中间价而不是通过盘口运行相同大小的订单。
- 确认导出格式、分页、速率限制和身份验证与小型集成。
- 除非提供商记录了这两个角色,否则将场馆交易 API 与研究存档分开。
Key takeaways
- 01当前的官方 API 和持续记录的历史存档解决了不同的问题。
- 02历史价格点不能替代历史订单簿深度。
- 03时间戳来源和明确的缺失数据策略是核心比较标准。
- 04有用的评估会重现一个大小的订单,而不仅仅是中间价。
- 05DepthFeed 统一了 Polymarket 和 Kalshi 的研究数据,而不会发明缺席的观察结果。
最佳 API 并非拥有最长端点列表的 API。 而是历史、时间戳、盘口深度和交付模型与系统需要复现的决策相匹配的 API。
免费开始