Bitget Reality API Open 8/11: 1/sec/UID Webhook Cap

Bitget Reality API shifted quietly on August 11: the changelog moved the Reality Order place/cancel endpoints out of whitelist-only status and opened them to all users. Any UTA (Unified Trading Account) account can now programmatically send orders for rToken tokenized U.S. stocks — this part is genuinely easy now.

What nobody warned you about is buried one line below in the same changelog: "default rate limit: 1/sec/UID". Webhook — the pipe that forwards TradingView alerts to your server — takes exactly one concurrent signal before the second one hits 429, and the signal is quietly dropped.

This article does not comment on whether rTokens are worth buying (that is an investment decision, and we do not make those here), and it does not compare tokenized-stock offerings — right now Bitget is the only exchange that ships this API. We only cover two things: what that one line in the changelog actually changed, and what 1/sec/UID means in practice for webhook-driven automation.

What the Bitget Reality API Changelog Actually Says

The entry on the Bitget UTA API changelog page dated 2026-08-11 is titled "Place/Cancel Reality Order: Now open to all users". The two endpoints changed are /api/v3/trade/place-reality-order and /api/v3/trade/cancel-reality-order. The body has exactly two sentences that matter.

First: "These endpoints no longer require whitelist access." — the two endpoints no longer sit behind a whitelist. Second: "Default rate limit: 1/sec/UID; whitelisted users: 30/sec/UID (users can contact your BD/RM to apply)." — the default is 1/sec/UID, whitelisted users get 30/sec/UID, and to apply you contact your BD or relationship manager.

What rToken Is and What You Can Trade

Reality is the RWA (real-world assets) issuance platform inside Bitget's ecosystem, and the first phase focuses on tokenized U.S. stocks and ETFs. Bitget Academy phrases it as "Each rToken is linked to a corresponding underlying asset, such as a publicly traded U.S. stock or ETF" — an rToken represents "economic exposure" to a U.S. stock or ETF, not shareholder rights.

The naming rule is a lowercase r prepended to the original ticker — for example rAAPLUSDT (Apple), rMUUSDT (Micron). Every instrument in the /api/v3/market/instruments response carries an isReality field (value is "yes" or "no") — it is a response field, not a query parameter, so pull the whole list and filter isReality === "yes" on the client. The list moves as Bitget adds and removes symbols, so we do not print a fixed roster here.

Only Place and Cancel Left the Whitelist — Everything Else Is Still Gated

What 1/sec/UID Actually Means

Rate limits are universal, but Bitget's counting unit here is UID. Not per API key, not per IP, not per symbol — every place-reality-order request coming out of the same UTA account shares one 1/sec budget.

In practice, for webhook automation: say you have 3 Pine strategies running on 1-minute bars, and on some bar close all three fire at once. Three place-reality-order requests arrive at Bitget's edge nearly simultaneously. The first succeeds; the second and third come back 429, and those signals are gone. This kind of failure does not shout — your log gets one line of 429, your strategy thinks the order went out, and in reality nothing happened.

How to Route Signals As They Come In

What to Do on Your Own Webhook Endpoint

• Route incoming signals through a local token bucket (capacity 1, refill 1/sec) before handing them to Bitget — take the 1-second delay in your strategy rather than let Bitget bounce your signal with a 429
• When Bitget returns 429, wait 1 second and retry, up to 3 times; if it still fails, log it clearly — this is normal for a webhook system, not a bug to eliminate
• When multiple strategies share the same UTA key, write the strategy ID into Bitget's clientOid field, so post-hoc reconciliation can tell which strategy placed which order
• Do not let multiple bar timeframes fire the same strategy at once; if you cannot avoid it, consider splitting them across different UTA sub-accounts

What a Reality Order Request Looks Like

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

Where TVSBot Sits Today

To be clear: TVSBot's current 7-exchange integration includes Bitget, but only for spot and perpetual futures — Reality Order is not wired up. Reality is an endpoint that lost its whitelist this month, and we have not scheduled it into an update yet. The point of this article is not to announce Reality as a TVSBot feature; it is to explain how this new API works, because some readers will wire it up themselves.

For readers already using TVSBot to connect Bitget spot/perp, we do handle rate limits on the webhook receiving side: after an alert arrives, we cap the same token at 60 requests per 60 seconds and the same IP at 30 per 30 seconds (backend/app/services/rate_limit.py). That is receive-side throttling; it is a separate layer from Bitget's 1/sec/UID. If you wire up Reality by hand, the Bitget-side rate limit is still yours to handle in your order module.

Honest Section: We Have Not Tested Reality Fill Behavior

This article describes what the API says in writing: the changelog text, the endpoint spec, the official rate limit number. But actual rToken fill depth, slippage, and behavior outside U.S. market hours — we have not tested that. Reality is a new product, tokenized U.S. stocks typically have thinner liquidity during Asian hours, and these details you can only learn by placing small orders yourself — documentation will not tell you what the order book looks like right now.

Frequently Asked Questions