DepthFeed。

市场数据产品必须做的不仅仅是返回价格。研究人员需要发现市场、选择正确的标识符、了解捕获的内容并检索可用的历史记录。网站、文档和 API 必须解释相同的契约。

DepthFeed 将预测市场元数据和记录的订单簿历史带入一个用于发现和研究的产品。其文档做出了一个重要区分：端点成功返回并不能证明底层数据是完整的。

该项目分离了服务 API、收集和historical ingestion、公共网站和账户体验以及客户端示例。这种分离允许公共解释和实现围绕定义的接口演进。

文档化的集成包括 REST 发现和历史，带有规范化的 WebSocket 订单簿和价格。账户政策、标识符、游标和时间戳保持明确，以便客户端不必推断服务的工作原理。

不同来源中的场地标签和标识符并不一定具有相同的含义。文档区分了候选关系与已确认的合同等效性，包括仍需审核的状态。

这既是产品设计决策，也是工程决策。用户在基于记录构建比较或分析之前，需要知道该记录能支持什么。清晰的状态比将不确定信息呈现为既定事实更有用。

这项工作将信息模型与网站、账户控制、API 文档和集成示例联系起来。它说明了产品开发为何需要在可见体验及其背后的系统之间保持一致的语言和状态。

交付经验教训是将文档和异常状态视为产品的一部分。集成合同应解释缺失的覆盖范围、身份验证和恢复机制，而不仅仅描述成功的请求。

DepthFeed 的公开产品和集成文档展示了市场记录、API 和研究界面如何协同工作。以下链接提供了当前的产品背景和集成参考。

覆盖范围和可用性因场地和市场而异。数据集成首先需根据当前文档检查所需的源、时间范围和访问方法。