只有价格不够 —— 把量一起拿走
odds 频道上的每个 outcome 都携带 limit：该价格上可接受的最大投注额，跨博彩商归一化，且几乎每家 sharp 博彩商都携带。
limit 与深度回答的是不同的问题
同一条赔率行上可能传来两个规模信号，把二者混为一谈是过度定量的常见方式：
limit约束的是单笔订单 —— 博彩商在这个价格上最多接受多少。- 阶梯（
meta.back/meta.lay，见于交易所与预测市场）约束的是成交结果 —— 触及价之后还挂着多少量，也就是清掉某个规模要付出多少成本。
limit 就是全部答案：一个数字、一笔订单，想要更多就只能等博彩商重新挂出。在交易所与预测市场上您两者兼有，且二者各自独立地构成约束 —— 面对一个稀薄的阶梯，再宽松的 limit 也只会成交得很差。
在有深度的地方，请以成交量加权均价而非触及价来给这笔成交定价。 沿阶梯走到您的目标规模，并使用由此得到的均价；只要超出第一档，盘口顶部价就是一个您拿不到的数字。按触及价定量，正是让建模出的优势在您最想做的那几笔交易上变成实际亏损的原因。
深度同样是按场馆计的，绝不能汇总。 把各家的阶梯加总，得到的是一个您无法据以交易的总量，因为一个场馆的订单不会去吃另一个场馆的挂单。请按博彩商建模可执行规模，再在选项层面做比较。
限额下调本身就是信号
限额变化以普通赔率更新的形式、在同一个oddsId 上到达，因此某家博彩商收紧可成交量会出现在同一条数据流中 —— 往往更早，也往往信息量更大。一家 sharp 博彩商维持价格却把限额砍半，这传达的信息是价格本身没有的。
若想利用这一点，请把限额历史与价格历史一并记录。REST 历史赔率接口承载同样的赔率行，因此该序列既可以实时观察，也可以事后重建。
掌握各博彩商的延迟
四个时间戳随数据一同传输，因此延迟是可验证的，而非假定的：changedAt − bookmakerChangedAt 即该条更新的观察延迟。各博彩商的上限发布在 GET /bookmakers（maxDelayLiveInSec、maxDelayPregameInSec、maxDelayPregameMainInSec），代表性滚动 p50 见延迟与新鲜度。
有两件事值得尽早接入：按成交记录 t0–t3，以便将糟糕的成交归因到正确的环节；以及部署在网关附近 —— 最后一跳是您唯一能掌控的部分。
当博彩商不再是最新时停止交易
请把
staleOdds 当作按博彩商的熔断开关，而不是一条警告 —— 陈旧的 sharp 盘口比没有盘口更糟，因为它看起来仍然可交易。
同时关注 bookmakers 频道上的 participantsRotated：某家博彩商的主客队分配若与 OddsPapi 基准不同，会被误读为并不存在的套利机会。
主盘与变更过滤
mainLine标记该博彩商在某盘口上的主盘，让您无需订阅所有替代盘口即可跟踪头部价格。GET /fixtures/odds/main在快照中仅返回主盘。- 赔率接口上的
since过滤（纪元毫秒）让您只回填发生变化的部分。参见时间戳。
marketId —— “大 2.5”与”大 3.5”是不同盘口，而非同一盘口的两个选项。计算水位与归一化时按 marketId 分组。
亚洲盘口
亚洲让分盘与四分之一盘是一等公民：marketType 为 spreads，线值在 handicap 中（例如 -0.25），结算在 WIN / LOSE / PUSH 之外返回 HALFWIN / HALFLOSS 用于半注结算。参见枚举 → settlementStatus。
对于以加密货币或非美元法币报价的博彩商，currencies 频道提供法币与加密货币对美元的汇率，用于本金与限额换算。
以收盘线给自己打分
用数据流交易，用 REST 测量。实时频道以固定约 10 毫秒窗口交付合并状态 —— 最新值始终会到达，但同一窗口内被取代的中间跳动不会，因此数据流不是逐跳账本。需要完整变动与开/收盘价时：
两者与实时数据流共用
oddsId 键（{fixtureId}:{bookmaker}:{outcomeId}:{playerId}），因此成交记录无需映射步骤即可关联到自己的收盘线。
1
记录成交
存储
oddsId、您的成交价，以及交易时刻的 t0–t3。2
拉取收盘
赛事开始后，对这些
oddsId 调用 /fixtures/odds/clv。3
打分
将成交价与收盘价对比得到 CLV，与记录的时间线（
/fixtures/odds/historical）对比做滑点归因。4
结算
使用
GET /fixtures/settlement 获取逐 outcome 结果，而不是自建结算逻辑。您可以依赖的保证
- 延迟按博彩商逐家公布，且为实测值。
maxDelayLiveInSec/maxDelayPregameInSec/maxDelayPregameMainInSec在博彩商提供可用时间戳时来自「观测时刻对比博彩商时刻」的实测，在其不提供时则明确标注为估算值。四段时间戳链意味着您可以用自己的时钟去核对这些数字，而不必只能选择相信。 - 不会丢弃任何变化。 更新在固定约 10 ms 的窗口内合并，最新值一定会送达 —— 数据流是最新状态，而非有损采样。需要每一跳时，REST 历史接口中都有。
- ID 跨赛季保持可寻址。 盘口分类法只追加 —— 随着覆盖增长会出现新的
marketType值，已有值的含义永不改变 —— 且同一组坐标始终解析到同一个marketId/outcomeId。针对上赛季数据编写的回测，今天寻址到的仍是同一批选项。