具体的正常运行时间目标、支持响应时间和补偿条款按 B2B 客户协议单独约定。请联系 contact@55-tech.com 讨论适合您用例的 SLA 条款。
实时状态与事件历史
平台的实时状态、正在进行的事件以及历史正常运行时间均发布在我们的状态页上：OddsPapi 状态页
实时可用性、事件报告和正常运行时间历史 —— 订阅以获取更新。
面向可用性的架构
平台经过设计，任何单点故障都不应中断您的数据流：- WebSocket 优先传输 —— 持久网关以最小延迟流式传输更新，避免 REST 轮询的开销与间隙。
- REST + WebSocket 冗余 —— REST 快照与实时数据流是通往同一数据的两条独立路径。如果数据流中断，REST 可使您的状态保持最新。
- 恢复与重放 —— 短暂断连后，客户端从其最后游标恢复并重放错过的更新，无需完整刷新。参见恢复和重放。
- 确定性恢复 —— 当无法重放时，网关发出
snapshot_required，客户端从快速的 REST 快照重建状态。恢复是一条明确的、经过设计的路径 —— 而非错误状态。
延迟与新鲜度
OddsPapi 的核心竞争力是可测量的端到端延迟 —— 而非吞吐量 —— 每条赔率更新都携带可用于验证的时间戳：changedAt − bookmakerChangedAt 即每条更新的观察延迟；将 ts 与您的接收时间对比即可得到传输跳延迟。
各博彩商的新鲜度上限发布在 GET /bookmakers：maxDelayLiveInSec、maxDelayPregameInSec 和 maxDelayPregameMainInSec 给出每个博彩商各交付模式的最大预期刷新延迟 —— 在博彩商提供可用时间戳时基于实测（当前为观察时间与博彩商变更时间差的滚动 p50），否则为估计值。
代表性的滚动 p50 观察延迟（各博彩商的实时数值见 GET /bookmakers）：
在观察之后，内部管道到网关发送约增加 30 毫秒（p50）；从
ts 到客户端接收的传输跳延迟取决于您的部署位置 —— 同区部署时可低至约 5 毫秒（参见服务器位置指南）。
如何在试用期亲自核验这些数字，参见评估数据源；如何用它们对标您已有的数据源，参见作为第二数据源运行 OddsPapi；如何据此交易，参见 sharp 盘口交易与 CLV。
博彩商陈旧度：staleOdds
可能失效的是两种不同的东西：平台（网关、您的连接），以及我们与各上游博彩商之间的链路。staleOdds 针对的是后者 —— 这个标志的含义是：该博彩商在该赛事上的赔率已不再可信，即便其他一切都正常。这正是一条价格可以同时看上去完美无缺又不可交易的原因 —— 下面是一次 REST 快照（GET /fixtures/odds），同一个响应同时携带两个映射；bookmakers 频道推送的是同样的 meta：
何时触发
该标志始终是被有意设置的，共有三种情形：- 失去联系 —— 博彩商侧的封锁、维护或宕机。我们完全无法再观察其价格。
- 异常静默 —— 每个博彩商都有一个监视器：如果整个博彩商在超过其专属阈值的时间内没有任何赔率变动，出于谨慎会将其全部赛事标记为陈旧。真正安静的时段（例如仅赛前盘的博彩商在深夜）也可能合理地触发它 —— 此时该标志的含义是我们暂时无法区分「安静」与「故障」，而这恰恰是您不应交易它的时刻。
- 错误映射 —— 被发现映射到错误博彩商赛事的 fixture 会被标记为陈旧，直到重新映射完成且旧价格被移除。这种情况下价格不是旧了，而是错了 —— 这正是
staleOdds是硬性阻断而非参考信号的原因。
层级与扩散
只有一条规则：staleOdds 恰好存在于一个层级 —— 赛事 × 博彩商。绝不会是盘口级或选项级（该标志覆盖这家博彩商在该赛事上的全部赔率），也绝不会是一条博彩商级的整体消息（博彩商范围的事件表现为该博彩商每个赛事上的标志）。各成因对应您会收到的消息：
因此请按
fixtureId:bookmaker 键值对存储与判定，与送达形式完全一致。如果您需要博彩商级的视图（例如「singbet 挂了」），请在您这一侧推导 —— 比如该博彩商当前被标记赛事的占比 —— 而不是等待一条永远不会到来的博彩商级消息。
它不是什么
它不是暂停。suspended 是博彩商自己对该赛事采取的动作，赔率行上的 active / marketActive 是博彩商在选项与盘口层面的停止。staleOdds 关乎我们的视野 —— 上述各项全部正常时它也可能为 true，反之亦然。两者各自独立意味着「此刻不要交易这家博彩商」。
处理方式
- 暂停对该博彩商、该赛事的交易与报价。
- 将持有价格视为未验证。 不要基于陈旧值重新定价。
- 待标志恢复
false后再继续。 恢复是自动的：每条更新都是完整的最新状态，随后的更新会自行重新验证您的存储 —— 无需重放或对账。 - 或者回退。 如果该博彩商是参考而非交易场所 —— 体育博彩商的风险衡量、做市的定价输入 —— 切换到其他仍在线、锐度相近的博彩商，标志清除后再切回。
为交易级故障转移而设计
恢复是有界且可预测的，而非尽力而为：- 网关缓冲一个重放窗口（
resumeWindowMs），因此短暂中断可无数据丢失地恢复。 - 如果您的游标超出该窗口，单次 REST 快照即可一次性恢复完整状态。
- 博彩公司连接状态通过
staleOdds标志明确呈现，因此您始终知道某个价格何时可能不再是最新的。
监控与运维责任
OddsPapi 为您提供安全运行所需的信号；您的客户端应据此采取行动：- 在基于某个价格进行交易前，按博彩公司跟踪
staleOdds标志。 - 处理
snapshot_required和重连逻辑（参见恢复和重放模板）。 - 遵守速率限制和 WebSocket 连接限制；如需为分布式系统提高限额，请联系支持。
- 关注状态页以了解平台级事件。
支持与事件响应
报告问题时，请提供您的
apiKey 组、受影响的频道或端点、时间戳（UTC），以及任何 serverEpoch / entryId 值 —— 这些可帮助我们快速追踪您的会话。