Bitget API rate limits
What is recorded about how fast you may call the Bitget API: 6 limit records, the wording from the record and no related error code yet.
Risk warning: CFDs and spread bets are complex instruments and come with a high risk of losing money rapidly due to leverage. You can lose money on these products, and each provider publishes its own loss figure under FCA rules. You should consider whether you understand how they work and whether you can afford to take the high risk of losing your money. Automated and API trading can amplify losses through bugs, connectivity failures and runaway orders.
Recorded limits
One record per limit. The scope is part of the limit: a figure is only useful once you know whether it applies to a key, an account, a session or an address.
| Limit | Value | Scope | Source |
|---|---|---|---|
| Public market data, legacy v1 API | 20 per 2 s per IP, public market data | Per IP address, public market data endpoints of the legacy v1 API | bitgetlimited.github.iochecked |
| Overall requests a minute | 6,000 | Per IP address, all requests to the common domain name, with REST and WebSocket sharing one allowance | bitget.comchecked |
| Concurrent WebSocket connections | 100 | Per IP address | bitget.comchecked |
| WebSocket messages a second | 10 | Per WebSocket connection, counting ping, login, subscribe and unsubscribe messages | bitget.comchecked |
| WebSocket subscription requests an hour | 240 | Per WebSocket connection | bitget.comchecked |
| Concurrent WebSocket channel subscriptions | 1,000 | Per WebSocket connection | bitget.comchecked |
Rate limits, as the record words them
- Rate limits, as worded
The quick start page for the current API states an overall limit of 6,000 requests a minute per IP on the common domain name, with each endpoint also carrying its own limit on its own documentation page, counted separately. REST and WebSocket share one allowance, and a breach returns HTTP 429. The response header x-mbx-used-remain-limit reports what is left for the endpoint called. Bitget's legacy v1 documentation, still published, states 20 requests in 2 seconds for public market data and 10 a second for a general endpoint with no figure of its own.
Bitget API quick start, Rate Limitchecked Bitget API docs (legacy v1), frequency limiting ruleschecked
Error codes that concern limits
Not recorded No decoded Bitget error names a rate limit yet.
Pacing and backoff, in general
This part is general advice and says nothing about Bitget in particular. The figures that apply are the recorded ones above, and the provider's own documentation is the authority.
Pace before you are refused. Work out the gap between requests that keeps you under the limit, then leave a margin, because a limit counted by a provider's clock will not line up exactly with yours. Spread calls evenly: a burst at the start of each window is the usual way to hit a limit while staying under it on average. The rate limit calculator checks a polling plan against a limit and gives the shortest interval that fits.
When a request is refused for rate, stop sending and wait. Double the wait after each refusal in a row, add a small random amount so that several programs do not retry together, and cap the number of attempts. If the reply names how long to wait, use that figure in place of your own.
Take extra care with dealing requests. A refused or unanswered order may or may not have gone through, so check the state of the order before you send it again. Cache what does not change, such as instrument details and history you have already downloaded, and prefer a stream to polling where one is offered.
Where to go next
- The full Bitget record
- Broker API rate limits compared
- HTTP 429 across broker APIs
- Rate limits for every broker and platform
- The fact register
Other brokers: Axi, Capital.com, CMC Markets, Deriv, Dukascopy, eToro, Exness, FOREX.com, FXCM, FxPro, IG, Interactive Brokers, OANDA, Pepperstone, Saxo, Swissquote, ThinkMarkets, Tickmill, Trading 212, XTB.