按 ID 关联，而非按名称
fixtures 频道在每条赛事上携带 externalProviders 对象：
如果您当前的数据源是其中之一，关联就是一个字段。每条赛事存一次，两套系统从此共享同一个键。
映射在存在对应关系时填充 —— 请将所有字段视为可空，并对其余部分回退到开赛时间加参与者的匹配方式。
博彩商侧映射
若需与博彩商自身的标识符（而非数据提供商的）关联，请使用映射接口：GET /futures/mapping 对冠军盘口做同样的事。在单条价格上，odds 频道还携带 bookmakerMarketId 与 bookmakerOutcomeId，bookmakers 频道携带 bookmakerFixtureId 与 fixturePath。
基于稳定键比较价格
在 OddsPapi 内部，一条价格的键是：{fixtureId}:{outcomeId}:{playerId} —— 这正是跨数据源比较时所需的，因为无论由谁报价，一个选项的输赢结果都相同。
要将某个选项对齐到另一路数据源的盘口模型，请拆解为坐标而非匹配盘口名称字符串：
marketType（1x2、totals、spreads 等）、period（fulltime、p1 等）与 handicap（线值）在 GET /markets 上均为显式字段。每个不同的线值都是独立的 marketId，因此”大 2.5”与”大 3.5”永远不会合并为一个盘口。参见盘口和选项。
1
映射赛事
通过
externalProviders 关联，或对博彩商侧 ID 使用 /fixtures/mapping。2
映射盘口
将您现有的模型翻译为
marketType + period + handicap，并从 /markets 解析出 marketId。3
映射方向
为该方向选取
outcomeId；球员盘口补上 playerId（否则为 0）。4
存储配对
持久化 您的键 ↔
{fixtureId}:{outcomeId}:{playerId}，使映射只做一次，而不是每次更新都做。测量哪一路更快
只有当您能判断哪一路更优时，第二次集成才值得。两项测量，均无需我方额外埋点：- 观察延迟 —— 每条更新的
changedAt − bookmakerChangedAt，与另一路数据源的等价时间戳对比。各博彩商的上限发布在GET /bookmakers（maxDelayLiveInSec/maxDelayPregameInSec/maxDelayPregameMainInSec），代表性 p50 见延迟与新鲜度。 - 传输跳 —— 信封
ts与您的接收时间对比。这一项取决于您的部署位置，参见服务器位置。
GET /fixtures/odds/clv 将成交价与收盘线对比。它与实时数据流共用 oddsId 格式，关联零成本。
通常的互补之处
覆盖范围很少完全重合，这正是并行两路的意义。实践中 OddsPapi 补足的是 sharp 交易型博彩商、亚洲盘口与四分之一盘结算、交易所与预测市场深度，以及几乎每家 sharp 博彩商都携带的投注限额 —— 同时具备广泛的美国与欧洲零售覆盖。目录形态参见博彩商覆盖，您的密钥可见范围参见GET /bookmakers。
切换检查清单
- 赛事已通过
externalProviders或/fixtures/mapping关联，并对空值有回退方案 - 盘口模型已翻译为
marketType/period/handicap坐标 - 存储以
oddsId为键，并保留用于跨源比较的选项键 -
staleOdds与suspended已接入与现有数据源相同的熔断开关 - 已实现
snapshot_required处理与恢复（恢复和重放） - 在转移任何权重之前，两路数据源上的延迟对比已在运行
您可以依赖的保证
- ID 不会在您脚下移动。 各注册表只追加，已发布的标识符被冻结，因此您在评估期建好的映射表一年后依然正确。新枚举值只会追加而不会被改作他用 —— 请忽略无法识别的值，而不是报错失败。
- 恢复是有界且确定的。 每频道游标（
serverEpoch+entryId）可在resumeWindowMs内重放；超出之后，最坏情况也只是一次 REST 快照，而不是到对账时才发现的静默缺口。 - 映射是双向可解的。
externalProviders让您用手上已有的供应商 ID 反查进来，GET /fixtures/mapping则两个方向都能走 —— 因此接第二路数据源是一次查表，而不是一个赛事匹配项目。