Broker API rate limits compared

Rate limits by API

Deeper references: IBKR Web API websocket topics and pacing, endpoint by endpoint, cTrader Open API limits and every payloadType

What to do with these numbers

• Read the scope before the number: a limit per IP address, per API key, per session or per connection changes how you split work across scripts.
• Back off on HTTP 429 and wait before retrying, doubling the wait each time.
• Keep one persistent connection where the broker recommends it (OANDA does) instead of opening new ones.
• On IG, allowance errors arrive as error codes such as error.public-api.exceeded-api-key-allowance; the exact HTTP status is not confirmed.

The backoff loop itself

One helper for any API in the table above that signals a rate limit with HTTP 429. It waits for the seconds in Retry-After when the reply carries one, doubles its own wait when it does not, and gives up after six tries rather than hammering the broker. Nothing is sent from this page.

# Back off on 429 and double the wait, which is what the list above asks for.
# Use the seconds in Retry-After when the reply carries one, and our own 1, 2, 4 up to 60
# seconds when it does not. Not every API in the table sends Retry-After.
import time

import requests


def call(method, url, tries=6, **kw):
    delay = 1
    for attempt in range(tries):
        resp = requests.request(method, url, timeout=10, **kw)
        if resp.status_code != 429:
            resp.raise_for_status()
            return resp
        header = resp.headers.get("Retry-After", "")
        wait = min(int(header) if header.strip().isdigit() else delay, 60)
        print("429 on", url, "- waiting", wait, "seconds before try", attempt + 2)
        time.sleep(wait)
        delay = min(delay * 2, 60)
    raise SystemExit("Still rate limited after " + str(tries) + " tries. Lower your request rate.")

IG is the exception on this site: it signals an exhausted allowance with an errorCode on HTTP 403 rather than a 429, and publishes no Retry-After, so this loop will never fire against it. The IG version of this helper branches on the errorCode instead.

IG allowances, one row each

IG splits its limits into allowances and returns an errorCode in the body rather than HTTP 429. This table is the full record of IG's limits on this site: one row per limit, with its scope, its source and the date that source was last checked. All five allowances were read on IG's developer FAQ at labs.ig.com/faq on 5 Oct 2026, and the same five values are what every other IG route here states. The record behind them is the ig-published-limits row of the fact register at /facts, which sources all five to the IG Labs FAQ. The three per account figures were withdrawn for the window of record 23 to 30 Sep 2026, while labs.ig.com/faq returned HTTP 500 on robots.txt, and were reinstated by the reading of 30 Sep 2026; that withdrawal is history, not the live reading. IG's own how to use the IG API page states a lower trading figure of around 40 a minute, also checked 5 Oct 2026. That conflict is labelled here and not resolved: pace dealing against 40 and treat 100 as the reference ceiling.

This table is the one canonical record of IG's limits on this site, last checked 5 Oct 2026. Every other IG route here states these same five values, with these scopes and this checked date, and shows fewer rows only where a shorter form is wanted. The matching error strings are error.public-api.exceeded-api-key-allowance, exceeded-account-allowance, exceeded-account-trading-allowance and exceeded-account-historical-data-allowance. Each one has its own page in the error dictionary. The block cleared. On 30 Sep 2026 labs.ig.com/faq opened and published all four allowances, so the per account figures have a page behind them again, and it opened again on 5 Oct 2026 with the same five figures. The labs.ig.com REST reference, the streaming reference and faq.html all failed on robots.txt with HTTP 500 on each attempt made on them, on 22, 23, 24 and 25 Sep 2026, and no workaround was attempted. That is why the figures were withdrawn. The withdrawal window of record, carried by the fact register, is 23 Sep 2026 to 30 Sep 2026, and the earlier description of it as five days is superseded.

Rate limits, with the denominator named, read 4 Oct 2026

Two readings follow from the right hand column rather than from the numbers. First, the limits that matter most are often not in the reference: IG’s five allowances exist only in an undated FAQ, OANDA’s three live on a development guide the introduction never points at, and TradeLocker’s and Deriv’s exist only at runtime behind a call to the API itself. Second, two of the eleven APIs here, Match-Trader and TradeLocker, publish no number at any address, which means a strategy built against them is pacing against something nobody has committed to in writing.

Sources: labs.ig.com FAQ · open-api.capital.com · OANDA development guide · Saxo rate limiting · cTrader Open API help · IBKR Campus Web API · IBKR Web API changelog · eToro rate limits · Trading 212 rate limiting · TradeLocker getting started · checked 4 Oct 2026

Independent and unofficial. Not affiliated with, endorsed by or operated by any firm named here.

OANDA rate limits: the numbers, and the page they are not on, 4 Oct 2026

OANDA does publish request rate limits, and they are not in the place a reader looks first. The v20 introduction and the REST reference carry none, which is the real gap; the numbers are on the development guide, and they were read again there on 4 Oct 2026.

One more OANDA figure exists and this site already labels it, so it is repeated here rather than left to be found: the best practices page states one hundred requests a second for established connections, against the development guide’s 120 a second per IP address. Both pages are OANDA’s and both are current. This site treats the development guide as the enforced reading because it names the denominator and the HTTP status, and it publishes the disagreement rather than choosing quietly.

What is worth criticising about OANDA’s documentation is therefore narrower and more useful than a missing number. The limits exist and are specific. They are simply not beside the endpoints they constrain, not mentioned in the introduction a reader starts from, and not dated. The introduction also still names a legacy API token with no deprecation date for the legacy API, under a copyright range ending in 2019.

Practical guidance, stated as guidance. Pace REST against 120 a second and remember the denominator is your IP address rather than your account, so a second process on the same host shares your allowance. Hold to 20 active streams and open new connections no faster than two a second. Back off on HTTP 429.

Sources: OANDA development guide, the page that carries the limits · OANDA v20 introduction, which does not · checked 4 Oct 2026

Independent and unofficial. Not affiliated with, endorsed by or operated by any firm named here.