Skip to main content

​
什么是 ABP？

自动投注（ABP） API 由 55-Tech 提供，让您通过单一集成在36家博彩公司进行投注。无需构建和维护各个博彩公司的连接器，ABP 处理从投注到结算的全部生命周期。 核心能力：
  • 账户管理 — 博彩公司账户的完整CRUD操作，支持优先级选择、每账户投注限额和多币种
  • 投注单获取 — 在下注前获取所有已配置博彩公司的任何赛事/结果的实时赔率和限额
  • 期货支持 — 独立的 /futures/* 端点用于冠军/期货盘，以 futureId + futureOutcomeId + participantId 作为键。在 OddsPapi 的 db-v2 标识符方案上线之前，所有期货端点均返回 501
  • 智能订单路由 — 下达单个或批量订单；ABP 自动按赔率和限额选择最佳博彩公司
  • 投注跟踪 — 从下注到确认和结算，完整审计追踪监控每一注
  • 持仓和盈亏分析 — 按博彩公司、账户或用户引用分组的汇总敞口和盈亏视图

​
数据流

1

通过 OddsPapi v5 发现赛事和赔率

您的应用使用 OddsPapi v5 API 发现赛事、市场、结果和实时赔率。OddsPapi 是数据层 — ABP 是建立在其之上的执行层。两个 API 共享赛事ID和结果ID。
2

从 ABP 获取投注单

下注前，调用 GET /fixtures/betslip?fixtureId=...&outcomeId=...&playerId=... 获取所有已配置博彩公司账户的汇总赔率和限额。期货盘有自己的路径——GET /futures/betslip?futureId=...&futureOutcomeId=...&participantId=...。ABP 解析投注限额（账户 > 博彩公司 > 赔率）并返回每个博彩公司的有效最小/最大值。
3

通过 ABP 下单

发送 POST /fixtures/place-orders 包含一个或多个订单。每个订单针对一场赛事（fixtureId + outcomeId + playerId）；期货字段会被拒绝。ABP 根据价格、可用限额和账户优先级将每个订单路由到最佳博彩公司。每个博彩公司集成下注并回报确认或拒绝。
4

通过 WebSocket 接收实时更新

连接 WS /ws 接收订单状态变更、投注确认、结算、余额更新和系统事件的实时推送。无需轮询。
5

查询历史和分析

使用 GET /fixtures/orders、GET /fixtures/bets 查询订单/投注历史（支持游标分页），使用 GET /positions、GET /pnl 查看汇总敞口和盈亏分析。

​
基础URL

​
两套端点：赛事与期货

一个选项要么是赛事（一场有开球时间的比赛），要么是期货（冠军盘，随赛季结束而结算），两者的标识 方式不同。各自拥有独立的路径前缀，这样任何端点都不必去猜它收到的是哪一类标识符： 两套端点都会以 422 拒绝对方的标识符，并在信息中指明你想要的路径。拆分只影响携带选项的四组 端点——投注单、订单、投注、盘口。/accounts、/bookmakers、/positions 和 /pnl 不涉及选项， 保持无前缀。
拆分前的路径仍然可用。 /betslip、/place-orders、/cancel-orders、/cancel-all-orders、 /orders、/bets、/bets/{bet_id} 和 /markets 是对应 /fixtures/* 端点的别名——同一处理 逻辑、同样的请求与响应——在参考文档中标记为已弃用，且没有下线日期。你生产环境中的现有调用无需 改动；新接入请使用 /fixtures/*。如果你此前尝试过冠军盘，有一个例外需要知悉：无前缀的赛事端点不再接受 futureId 或 participantId。它们以前返回 501，现在返回 422（下单）或 400（投注单），并指向 /futures/*。

​
关键概念

​
订单 vs 投注

订单是您的下注指令。投注是在博彩公司实际放置的注单。使用部分成交或多博彩公司路由时，一个订单可能产生多个投注。

​
请求去重

每个订单需要唯一的 requestUuid（UUID格式）。ABP 使用服务端去重（30分钟TTL）防止重复下注。重复的订单会被静默跳过；如果请求中的每个订单都是重复的，则请求返回 409 Conflict。

​
订单生命周期

  • PENDING — 订单已接收并排队
  • PROCESSING — 正在路由到博彩公司
  • FILLED — 全部投注额已成功下注
  • PARTIALLY_FILLED — 部分投注额已下注，剩余已过期或无容量
  • REJECTED — 验证失败（赔率不对、赛事无效等）
  • EXPIRED — 订单 expiresAt 时间已到（默认：5秒，最长：24小时）
  • CANCELLED — 客户端显式取消
  • FAILED — 下注过程中出现内部错误

​
投注生命周期

  • PENDING — 投注已创建，等待博彩公司响应
  • PLACED — 已发送到博彩公司，等待确认
  • CONFIRMED — 博彩公司已接受投注
  • REJECTED — 博彩公司拒绝了投注
  • CANCELLED — 确认前投注已取消
  • FAILED — 下注过程中出现内部错误
  • VOID — 博彩公司取消了投注

​
结算生命周期

  • UNSETTLED — 投注进行中，等待结果
  • WON — 全赢
  • LOST — 全输
  • VOID — 投注作废（退还投注额）
  • HALF_WON — 亚洲盘部分赢
  • HALF_LOST — 亚洲盘部分输
  • PUSH — 退还投注额（平局）
  • CASHOUT — 以协商价格提前提款

​
账户优先级

每个博彩公司账户有一个 priority 字段（值越高越优先）。下单时，ABP 为每个博彩公司优先选择最高优先级的活跃账户。

​
限额级联

投注限额按优先级顺序解析：账户限额 > 博彩公司限额 > 赔率限额。 例如，如果账户 minStake: 10，博彩公司默认 minStake: 1，赔率条目显示 limitMin: 5，有效最低值为 10（来自账户覆盖）。

​
期货（冠军盘）

期货位于 /futures/* 之下。一个期货盘由 futureId 标识，选项则是 (futureOutcomeId, participantId) 这一对值。期货没有 playerId——participantId 同时承担 球队与球员的指代——也没有 period。 通过 futureOutcomeId 区分的两种盘口形态： 没有指向任何选项的组合（futureOutcomeId=0 且 participantId=0）会被拒绝。 整套期货端点目前都返回 501，原因有两条，且会分别解除：
  1. 标识符方案。 ABP 只识别 OddsPapi 的 db-v2 期货标识符，形如 id1012639310001。当前数据源仍发布纯整数 id，ABP 会拒绝（400）而不去猜测，因此期货数据接入是关闭的，也就没有任何缓存可供返回。db-v2 上线后（预计 2026 年 10 月下旬）这一条解除。
  2. 存储。 下单、撤单、GET /futures/orders 与 GET /futures/bets 还额外需要 orders 表上的期货标识列——而把 futureId 写进赛事的列里，正是这次拆分要消除的混用。
路由、参数与校验都已定稿，并且返回 501 的端点会先校验你的请求体：格式错误的 futureId 或空的 选项组合今天同样得到 422/400。现在就可以按它们集成，日后只有 501 会变化。 期货真正开启后，其赔率以数据源为准——仅来自 OddsPapi 缓存，因此账户上的 verifyBetslip 对这套端点 没有影响。
请把 oddsId 当作不透明字符串。 保存并原样回传，不要解析它。ABP 始终发布实际命中的那个键—— 保存所收到 id 的客户端不受格式变更影响，而按 : 拆分它的客户端会出错。

​
博彩公司标识

博彩公司通过标识字符串识别（例如 pinnacle、betfair-ex、polymarket）。使用 GET /bookmakers 列出所有36家支持的博彩公司及其默认投注限额。

​
端点一览

上述携带选项的端点同样可以在不带 /fixtures 前缀的情况下访问（/betslip、/place-orders 等）——已弃用的别名，行为不变。

​
支持的博彩公司

传统体育博彩： pinnacle, pinnacleb2b, betamapola, betcris, betwar, bookmaker.eu, cloudbet, cloudbetb2b, justbet, kaiyun, matchbook, monkeyline.vip, novig.us, 198bet, paradisewager, sharp.ag, sharpbet, singbet, sports411.ag, 3et, 3etpp 博彩交易所： betfair-ex, betdex, smarkets, limitless-ex 预测市场： polymarket, polymarket.us, kalshi, predict.fun, prophetx, sx.bet, vertex, topodds, 4casters Punter平台： punter.io, punter.iopp

​
可靠性

ABP 包含生产级可靠性功能：
  • 熔断器 — 每博彩公司熔断器防止级联故障并自动恢复
  • 指数退避重试 — 用于瞬态故障
  • 紧急控制 — 在系统维护期间订单可能会被临时暂停
  • 速率限制 — 每API密钥的速率限制（每客户可配置）

​
数据源

ABP 从 OddsPapi v5 获取实时赔率数据。ABP 中的赛事ID和结果ID直接对应 OddsPapi 标识符。您的应用应使用 OddsPapi 发现赛事和市场，然后使用 ABP 执行投注。

​
常见问题

ABP 直接向博彩公司下注——它不是对冲或做市引擎。您发送订单，ABP 将其路由到最优账户、下注并跟踪至结算。数据层是 OddsPapi v5；ABP 是其上的执行层。
订单是您下注的指令。投注是在博彩公司实际下达的赌注。当涉及部分成交或多博彩公司路由时，一个订单可产生多个投注。详见核心概念。
每个订单携带唯一的 requestUuid（UUID 格式）。ABP 在服务端去重 30 分钟——重复订单会被静默跳过；若请求中每个订单都是重复的，则返回 409 Conflict。详见核心概念。
支持。设置 acceptPartialStake: true 让单个订单跨多个投注成交，并传入 bookmakers 列表（或省略以自动选择）以分散到多个场所。ABP 强制执行加权平均价格约束，使您的有效价格保持在 orderPrice 或以上。详见订单下注。
涵盖传统体育博彩、博彩交易所、预测市场和 Punter 平台共 36 家博彩公司。各场所的能力（清扫、结算、投注单）有所不同——见博彩公司能力矩阵。
可以。设置 testOrder: true 会走完整的校验与路由流程（额度、价格检查、账户选择），但不会向博彩公司发送投注——这是上线前确认请求体与 ID 正确的最快方式。见快速入门。
ABP 运行每博彩公司熔断器、带退避的重试、两级紧急控制，以及带 ack/replay 的可靠 WebSocket 投递。断连后的恢复是有界的——通过 REST 对账任何 seq 间隙。见可靠性与运维。

​
💬 询问 AI 助手

想用您喜欢的 AI 探索或询问关于此 API 的问题吗？ 点击下方任一链接——每个链接都会在所选工具中打开完整文档包并附带预填提示：

​
下一步

身份验证

设置您的API密钥。

快速入门

5步完成您的首次投注。