Bitget Reality API 8/11：1/sec/UID 限速接 webhook

Bitget Reality API 在 8 月 11 日悄悄变天：changelog 把 Reality Order 的下单／撤单 endpoint 从白名单改成全用户开放。任何 UTA（Unified Trading Account）账户都能程式化下 rToken 代币化美股的单，这件事现在真的不难。

没有人先跟你讲的是：同一则 changelog 底下藏了一行「default rate limit: 1/sec/UID」。webhook——也就是 TradingView 把 alert 自动转发到你服务器的那条通道——一有并发信号，第 2 笔就会撞 429，信号会安静地被丢掉。

这篇不评论 rToken 适不适合买（那是投资判断，本文不做），也不比较谁家的代币化股票更好——目前只有 Bitget 开这条 API。我们只讲两件事：changelog 这行字到底改了什么、以及 1/sec/UID 这个门槛对 webhook 自动化系统的实际影响。

Bitget Reality API 的 changelog 这一条到底写了什么

Bitget UTA API 的 changelog 页面 2026-08-11 这一条标题是「Place/Cancel Reality Order: Now open to all users」。改动的两个 endpoint 是 /api/v3/trade/place-reality-order 与 /api/v3/trade/cancel-reality-order。正文的关键句只有两行。

第一行：「These endpoints no longer require whitelist access.」——这两支 endpoint 不再需要白名单。第二行：「Default rate limit: 1/sec/UID; whitelisted users: 30/sec/UID (users can contact your BD/RM to apply).」——默认限速是 1/sec/UID，白名单用户 30/sec/UID，要申请请联系 BD 或客户经理。

rToken 是什么、能交易哪些

Reality 是 Bitget 生态系里的 RWA（real-world assets，真实世界资产）发行平台，第一阶段主要做的是代币化美股与 ETF。Bitget Academy 的原文写「Each rToken is linked to a corresponding underlying asset, such as a publicly traded U.S. stock or ETF」——rToken 代表对某支美股或 ETF 的「economic exposure」（经济敞口），不是股东权利。

命名规则是原本的美股代号前面加 r，例如 rAAPLUSDT（Apple）、rMUUSDT（Micron）。/api/v3/market/instruments 每笔 instrument 的响应都有 isReality 字段（值是 "yes" 或 "no"）——它是 response 字段、不是 query 参数，抓整份清单回来后自己在 client 端筛 isReality === "yes"。名单会随 Bitget 上下架调整，本文不列固定清单。

拿掉白名单的只有 place 跟 cancel，其他都还锁着

1/sec/UID 这条门槛的意思

rate limit 这件事每个交易所都有，Bitget 这条的计算单位是 UID。不是每支 API key 各 1 次、不是每个 IP 各 1 次，也不是每个 symbol 各 1 次——同一个 UTA 账户产生的所有 place-reality-order 请求，全部共用这 1/sec 的预算。

对 webhook 自动化的实际后果：假设你有 3 条 Pine 策略跑在 1 分钟 K 线上，某根 K 线收线时同时触发，三笔 place-reality-order 几乎同时到达 Bitget 端。第 1 笔会成功，第 2 与第 3 笔会拿到 429 错误，信号就这样消失。这种错不会吵——log 里就一行 429，你的策略以为单下出去了，实际上什么都没发生。

信号进来后该怎么分流

你在自己的 webhook 端该做什么

• webhook 收到信号后先过本地 token bucket（容量 1、每秒补 1）再丢给 Bitget，宁可让策略延迟 1 秒也不要让信号被 Bitget 端挡回 429
• Bitget 回 429 时等 1 秒后重送，最多 3 次；仍失败就明确 log 出来——这是 webhook 系统的常态，不是要修的 bug
• 多策略共用同一个 UTA key 时，把「策略 ID」写进 Bitget 的 clientOid 字段，事后对账才分得清楚是哪条策略的单
• 不要让多个 K 周期同时触发同一支策略；真的无法避免，考虑拆到不同 UTA sub-account 各自跑

Reality Order 的下单字段长什么样

{
          "category": "SPOT",
          "symbol": "rAAPLUSDT",
          "side": "buy",
          "orderType": "limit",
          "qty": "1",
          "price": "180.50",
          "clientOid": "strategy-42-signal-001"
        }

TVSBot 目前的位置

先讲清楚：TVSBot 目前的 7 家交易所整合里，Bitget 是有的，但范围只到 spot 与 perpetual futures——Reality Order 还没接。Reality 是这个月才拿掉白名单的 endpoint，我们也还没把它排进更新。这篇的目的不是宣布 Reality 是 TVSBot 现有功能，是把这个新 API 的机制讲清楚，因为读者里有些人会自己接。

对于已经用 TVSBot 接 Bitget spot/perp 的读者，rate limit 这件事我们在 webhook 收讯端有做：收到 alert 之后同 token 60 秒内最多 60 条、同 IP 30 秒 30 条（backend/app/services/rate_limit.py）。这是收讯端的 throttle，跟 Bitget 端的 1/sec/UID 是两层独立的限速。要手动接 Reality 的话，Bitget 那层的 rate limit 还是要自己在下单模块处理。

诚实的一段：我们没有实测 Reality 的成交行为

这篇描述的是 API 白纸黑字的部分：changelog 原文、endpoint 的 spec、rate limit 的官方数字。但实际下 rToken 单的成交深度、滑点、非美股交易时段的行为，我们没有实测。Reality 是新产品，代币化美股在亚洲时段的流动性通常较差，这几件事只能你自己下小单试——文件不会告诉你当下的 order book 长什么样子。

常见问题