Broker API rate limit calculator
Choose a published limit and say how often you plan to call. See whether the plan fits, the headroom left and the shortest interval that would.
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.
Check a plan against a limit
This is arithmetic on published figures, not a guarantee. A provider can count differently from its own page, and can change a limit without notice.
The figures this tool uses
A limit can be chosen above when its record holds one figure and one window, or one ceiling: 24 are recorded as a number and a unit, and 10 are recorded as wording that opens with a count and a window, such as 20 per 2 s, which is taken as it stands. Each is shown here as its record holds it. A figure without its scope is not usable: the scope says what is being counted, and two figures with different scopes are separate limits that can both apply at once.
Bitget API rate limits
| 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 |
Capital.com API rate limits
| Limit | Value | Scope | Source |
|---|---|---|---|
| Headline limit | 10/s per user | user | open-api.capital.comchecked |
cTrader API rate limits
| Limit | Value | Scope | Source |
|---|---|---|---|
| Requests a second, not historical data | 50 | Per connection, requests that are not for historical data | help.ctrader.comchecked |
| Requests a second, historical data | 5 | Per connection, historical data requests only | help.ctrader.comchecked |
Deriv API rate limits
| Limit | Value | Scope | Source |
|---|---|---|---|
| Headline limit | 80/min per logged in user (REST)Sources conflict developers.deriv.com states 60, checked . Deriv's API overview in the text form it publishes for AI tools gives REST 60 requests a minute per token, where its Limits page gives 80 a minute per logged in user. The same overview also gives 100 WebSocket requests a second per connection, 100 active subscriptions per connection and 5 concurrent WebSocket connections per user, none of which the Limits page mentions. Deriv's own pages disagree; the conflict is labelled, not resolved. Pace against 60. | user, REST | developers.deriv.comchecked |
Dukascopy API rate limits
| Limit | Value | Scope | Source |
|---|---|---|---|
| Connection attempts a minute | 5 | Per IP address, per FIX server | dukascopy.comchecked |
| Open positions | 100 | FIX API. The guide does not say whether the count is per session or per account | dukascopy.comchecked |
| Orders a second | 16 | FIX API, orders only. The guide does not say whether the count is per session or per account | dukascopy.comchecked |
eToro API rate limits
| Limit | Value | Scope | Source |
|---|---|---|---|
| Headline limit | 60/min reads per key | user | api-portal.etoro.comchecked |
FOREX.com API rate limits
| Limit | Value | Scope | Source |
|---|---|---|---|
| Request throttle | 500 requests per 5 s, HTTP 429 above it | Requests from one client application. The page does not say whether the count is per session, per AppKey or per IP address | docs.labs.gaincapital.comchecked |
IG API rate limits
| Limit | Value | Scope | Source |
|---|---|---|---|
| Historical price data points a week | 10,000 | Per account, price history endpoints only | labs.ig.comchecked |
| Non trading requests a minute | 30 | Per account, non trading calls only | labs.ig.comchecked |
| Non trading requests a minute | 60 | Per application, that is per API key, non trading calls only | labs.ig.comchecked |
| Concurrent streaming subscriptions | 40 | Per streaming connection | labs.ig.comchecked corroborated by labs.ig.com/streaming-api-guide.html |
| Trading requests a minute | 100Sources conflict ig.com states around 40, checked . IG's own pages disagree. The conflict is labelled, not resolved. Pace against 40. | Per account, trading calls only | labs.ig.comchecked |
Interactive Brokers API rate limits
| Limit | Value | Scope | Source |
|---|---|---|---|
| Global requests a second (Web API) | 10 | Per authenticated username, that is per Web API session | ibkrcampus.comchecked corroborated by interactivebrokers.com/docs/web-api/trading/usage-and-availability/pacing-limitations |
| Market data snapshot requests a second | 10 | GET /iserver/marketdata/snapshot only | interactivebrokers.comchecked corroborated by ibkrcampus.com/campus/ibkr-api-page/webapi-doc/ |
| Order and trade list requests | 1 req/5 s | GET /iserver/orders and GET /iserver/trades, each counted on its own | interactivebrokers.comchecked corroborated by ibkrcampus.com/campus/ibkr-api-page/webapi-doc/ |
| Session validation requests a minute | 1 | GET /sso/validate only | interactivebrokers.comchecked corroborated by ibkrcampus.com/campus/ibkr-api-page/webapi-doc/ |
| Session keep alive requests a second | 1 | GET /tickle only | interactivebrokers.comchecked corroborated by ibkrcampus.com/campus/ibkr-api-page/webapi-doc/ |
MetaApi API rate limits
| Limit | Value | Scope | Source |
|---|---|---|---|
| CPU credits per account | 5,000 CPU credits per 10 seconds | Per MetaTrader account. REST and RPC calls only | metaapi.cloudchecked |
| CPU credits an hour, per application | 18,000 | Per application, multiplied by the number of accounts deployed to MetaApi. REST and RPC calls only, counted in CPU credits and not in requests | metaapi.cloudchecked |
| CPU credits a minute, per application | 6,000 | Per application, multiplied by the number of accounts deployed to MetaApi. REST and RPC calls only, counted in CPU credits and not in requests | metaapi.cloudchecked |
| CPU credits a second, per application | 1,000 | Per application, multiplied by the number of accounts deployed to MetaApi. REST and RPC calls only, counted in CPU credits and not in requests | metaapi.cloudchecked |
| Concurrent historical market data requests | 5 | Per MetaTrader account, historical market data API only | metaapi.cloudchecked |
| CPU credits a second, per server | 2,000 | Per shared front end server. REST and RPC calls only, counted in CPU credits and not in requests | metaapi.cloudchecked |
OANDA API rate limits
| Limit | Value | Scope | Source |
|---|---|---|---|
| Headline limit | 120/s per IP address, HTTP 429 above it | ip | developer.oanda.comchecked |
Saxo API rate limits
| Limit | Value | Scope | Source |
|---|---|---|---|
| Headline limit | 120/min per session, per service group | session | developer.saxochecked |
Trading 212 API rate limits
| Limit | Value | Scope | Source |
|---|---|---|---|
| Headline limit | 1 req/5s, account summary (example) | account | docs.trading212.comchecked |
1 of the 35 limit records that cannot be offered, and why
- Interactive Brokers, Historical market data requests. As recorded: Either 10 req/s or 50 req/minute, as the page words it. Not offered because its wording does not open with one count and one window, so no single figure can be taken from it without reading meaning into the sentence.
They are on the rate limit pages with their scope and source, and the custom mode will take any figure you read there yourself.
What it does, and what it cannot tell you
It multiplies the calls in one round by the number of rounds that fit in the limit's window, and compares the result with the limit. The shortest interval is the gap between rounds at which the plan would sit exactly at the limit.
Where a record carries two readings that disagree, the sum uses the lower one and shows both, each with its source. The conflict is labelled, not resolved.
It cannot tell you how the provider counts. Whether the window rolls or resets on the clock is not recorded here. Nor is what else is counted against the same scope: another program on the same key or account spends the same allowance. Treat the result as a ceiling to stay well under, and handle a refusal in code anyway.