ABP 为生产级交易而构建。按博彩商的熔断器、自动重试与两级紧急系统，可防止单个失败的博彩商级联拖垮整体。本页解释会影响你集成的行为及应对方式。
系统状态
状态与可用性
实时系统状态通过
GET /status（无需鉴权）暴露。可轮询它，或订阅 status 与 emergency WebSocket 频道以接收推送。速率限制
速率限制按客户端（由你的x-api-key 解析）使用滑动窗口实施。默认值为每秒 100 个请求，可通过 rps 字段按客户端配置。
每个被限流的响应都包含标准响应头，便于你调整客户端节奏：
429 响应体：
retry_after 的短暂退避即可。针对速率限制使用指数退避并无额外收益；等待窗口过去即可。
POST /place-orders 可在一个请求中接受多个订单）、优先使用 WebSocket 而非轮询，并在工作负载需要更大余量时通过支持申请更高的 rps。WebSocket 连接上限见 WebSocket → 连接限制。
熔断器
ABP 运行按博彩商的熔断器。若某博彩商开始失败，其熔断器会打开，指向它的订单将被拒绝（Bookmaker not available），而非挂起。
- 在对某博彩商连续失败后打开。
- 冷却后自动半开以测试恢复。
- 一旦博彩商成功响应即关闭并恢复正常路由。
带退避的重试
短暂的博彩商故障会以指数退避自动重试，且 ABP 在每次重试前都会拉取最新赔率。重试受订单expiresAt 约束，因此慢速博彩商绝不会让订单超过其过期时间仍被阻塞。
订单过期
EXPIRED（若已部分成交则为 PARTIALLY_FILLED）。对时效要求较低的订单设置更长的 expiresAt，对价格纪律更严的订单设置更短的值。
紧急模式（两级）
在极少数情况下——维护或上游事件——ABP 可暂停订单处理。共分两级：
状态变更通过
emergency WebSocket 频道广播。紧急模式生效时，POST /place-orders 会返回被拒而非排队。
WebSocket 可靠投递
对于不能丢失的状态（订单成交、结算），在登录时启用reliableDelivery: true 以获得带确认与重放的至少一次投递。seq 出现间隙即表示漏掉消息；通过 replay 恢复，或经 GET /orders / GET /bets 对账。参见 WebSocket。
你的职责
为在客户端保持韧性：- 把被拒视为正常流程——处理
declinedOrders与被拒原因，而非假设每个订单都会成交。 - 重连后对账——WebSocket 断开后，从最后的
seq重放，或重新查询 REST 端点。 - 遵守幂等——重试时复用同一个
requestUuid，使重连风暴无法造成重复下注。参见核心概念。 - 429 时退避——参见上文速率限制。
支持与事件
上报事件时，请附上相关的
orderId / requestUuid、博彩商 slug 与 UTC 时间戳——这能大幅加快诊断。
后续步骤
WebSocket
带可靠投递与重放的实时更新。
错误处理
状态码与被拒原因。