IBKR-API-Pacing: Limits verstehen, Sperren vermeiden.

Die TWS API von Interactive Brokers erlaubt pro Sekunde so viele Anfragen, wie Ihr Konto Marktdatenlinien hat, geteilt durch zwei: Mit den standardmäßigen 100 Linien sind das 50 Anfragen pro Sekunde. Wer darüber liegt, bekommt je nach TWS-Einstellung Fehler 100 und nach drei Verstößen eine getrennte Verbindung, oder TWS bremst die Anfragen unbemerkt selbst. Für historische Daten, Tick-by-Tick, Markttiefe, die Web API und den Flex Web Service gelten eigene, teils deutlich engere Grenzen. Dieser Artikel fasst die wichtigsten Anfrage-Limits an einem Ort zusammen (Stand Oktober 2026, laut IBKR-Dokumentation), ordnet jeder Fehlermeldung das passende Limit zu und zeigt ein Token-Bucket-Muster in Python mit asyncio, mit dem ein Bot sauber drosselt, statt gesperrt zu werden. Die Zahlen ändern sich gelegentlich; prüfen Sie vor dem Live-Betrieb die aktuelle Doku.

Was bedeutet Pacing bei Interactive Brokers?

Pacing heißt bei Interactive Brokers die Begrenzung, wie viele Anfragen ein Programm in einem bestimmten Zeitraum stellen darf. Eine Anfrage ist laut IBKR-Dokumentation eine vom Nutzer abgeschickte Abfrage, um Daten zu erhalten: ein Kursabo für ein Instrument, eine Kontraktdefinition, ein Block historischer Kerzen. Ein Abo zählt dabei nur einmal. Die erste Anfrage, die den Datenstrom startet, fließt ins Limit ein, die danach gelieferten Kursupdates nicht.

Für Trading-Bots ist das wichtig, weil die meisten Pacing-Probleme nicht im laufenden Handel entstehen, sondern beim Start und beim Nachladen. Typisches Beispiel: Ein Bot startet morgens, fragt für 300 Symbole die Kontraktdetails ab, abonniert Kurse und lädt die Kerzen der letzten Tage nach. Ohne Drosselung schickt er in der ersten Sekunde Hunderte Anfragen ab. Genau dann greifen die Limits, und der Bot steht ohne Daten da, bevor er überhaupt eine Order gesendet hat.

Interactive Brokers kennt nicht ein Limit, sondern mehrere Ebenen: eine Grundregel für alle Anfragen an TWS oder IB Gateway, Sonderregeln für datenintensive Abfragen, eigene Grenzen in der Web API und im Flex Web Service sowie mit der Order Efficiency Ratio eine Kennzahl für das Orderverhalten. Wer diese Ebenen auseinanderhält, findet die Ursache einer Fehlermeldung deutlich schneller und drosselt an der richtigen Stelle.

Wie viele Anfragen pro Sekunde erlaubt die TWS API?

Die Grundregel, oft auch Rate Limit genannt, steht in der TWS-API-Doku: Die maximale Zahl an Anfragen pro Sekunde entspricht den Marktdatenlinien des Kontos geteilt durch 2. Marktdatenlinien sind die Zahl der Instrumente, für die Sie gleichzeitig Echtzeitkurse beziehen können. Sie gelten für die TWS-Watchlist und die API zusammen. Standardmäßig hat jedes Konto 100 Linien, daraus ergeben sich 50 Anfragen pro Sekunde. Mit 200 Linien sind es 100 pro Sekunde, und so weiter.

Mehr Linien gibt es auf zwei Wegen. Nach dem ersten Monat berechnet IBKR die Linien als größten Wert aus drei Größen: Monatskommission in USD geteilt durch 8, Kontowert in USD mal 100 geteilt durch 1 Million, und das Minimum von 100. Rechenbeispiel aus der IBKR-Doku: 500 USD Kommission und 1.245.000 USD Kontowert ergeben 124 Linien, daraus folgen 62 Anfragen pro Sekunde. Der zweite Weg sind kostenpflichtige Quote-Booster-Pakete mit je 100 zusätzlichen Linien. Wer weniger als 800 USD Monatskommission und weniger als 1 Million USD Kontowert hat und keinen Booster bucht, bleibt nach dieser Formel bei 100 Linien.

Die Fehlerliste beschreibt Code 100 pauschal mit 50 Nachrichten pro Sekunde und warnt, dass TWS die Verbindung danach wahrscheinlich trennt. Planen Sie mit dem Wert, der für Ihr Konto gilt, und lassen Sie Puffer. IBKR weist außerdem darauf hin, dass bei mehr als 50 Anfragen pro Sekunde einzelne Orders in eine Warteschlange geraten und verzögert werden können. Für solche Lasten verweist IBKR auf die FIX-Schnittstelle, die über IB Gateway 250 Nachrichten pro Sekunde zulässt. Für einen Bot mit einigen Dutzend Instrumenten reicht meist ein Start, der Anfragen staffelt.

Ablehnen oder drosseln: die TWS-Einstellung und ihre Folgen.

Was bei einem Verstoß passiert, legen Sie selbst fest. In TWS und IB Gateway gibt es unter Global Configuration, API, Settings die Option „Reject messages above maximum allowed message rate vs applying pacing“. Sie kennt zwei Zustände mit sehr unterschiedlichen Folgen:

• Angehakt (ablehnen): TWS meldet jede Überschreitung mit Fehler 100. Nach drei Verstößen beendet TWS die API-Sitzung. Im Programm zeigt sich das als WinError 10053 unter Windows oder als BrokenPipe unter macOS und Linux.
• Nicht angehakt (drosseln): TWS bremst die Anfragen selbst. Laut Doku wartet das System mit der Bestätigung von Anfragen im EReader-Thread, bevor es neue annimmt.

Drosseln klingt bequemer, hat aber einen Haken: Die Verzögerung ist unsichtbar. Ihr Bot schickt eine Stornierung ab und weiß nicht, dass sie hinter Dutzenden Datenanfragen wartet. In ruhigen Phasen fällt das nicht auf, in hektischen Marktphasen kann es über eine rechtzeitige oder zu späte Reaktion entscheiden. Ablehnen ist strenger, macht Fehler aber sichtbar. Dafür muss der Code Fehler 100 auswerten und nach dem ersten Treffer langsamer werden, sonst ist die Sitzung nach dem dritten Verstoß weg.

Sinnvoll ist eine Kombination: eine eigene Drosselung im Code, die das Limit gar nicht erst erreicht, plus die Ablehnen-Einstellung als Frühwarnung. Tritt Fehler 100 dann doch auf, deutet das auf einen Fehler in der eigenen Logik hin, etwa eine Schleife, die bei jedem Kursupdate neue Anfragen stellt. Wer mit Python arbeitet, sollte wissen, dass die Bibliothek ib_async bereits selbst drosselt: Ihr Client begrenzt ausgehende Nachrichten standardmäßig auf 45 pro Sekunde (Einstellung MaxRequests, der Wert 0 schaltet die Drosselung ab). Die Grundlagen der Anbindung beschreibt der Praxis-Leitfaden zur IB-API mit Python.

Sonderlimits für Historie, Tick-by-Tick und Markttiefe.

Neben der Grundregel gibt es Grenzen für Abfragen, die viel Datenvolumen erzeugen. Sie sind deutlich enger. Die Grenzen für kleine historische Bars lassen sich laut IBKR nicht verändern; Tick-by-Tick und Markttiefe wachsen nur mit der Zahl der Marktdatenlinien. Die Doku begründet das offen: Interactive Brokers sei kein spezialisierter Marktdatenanbieter. Wem die Grenzen nicht reichen, dem empfiehlt IBKR einen spezialisierten Datenanbieter.

Die Historie-Regeln treffen vor allem Bots, die beim Start viele Symbole nachladen oder lange Zeiträume in kleinen Stücken abfragen. Rechenbeispiel: 60 Anfragen in 10 Minuten bedeuten im Schnitt eine Anfrage alle 10 Sekunden. Wer für 50 Symbole je drei Blöcke 30-Sekunden-Bars braucht, also 150 Anfragen, muss mit rund 25 Minuten Ladezeit rechnen, nicht mit wenigen Sekunden. Ein lokaler Speicher für bereits geladene Daten spart die meisten Anfragen.

Fehler 162 ist die Sammelmeldung des Historiendienstes. Er kann auch andere Ursachen haben, etwa fehlende Datenberechtigungen oder einen Zeitraum, für den es keine Daten gibt. Werten Sie deshalb immer den Meldungstext aus, nicht nur den Code. Fehler 420 („Invalid real-time query“) führt die IBKR-Fehlerliste ebenfalls mit einem Verweis auf Pacing-Verstöße.

Web API und Flex Web Service: andere Regeln, HTTP 429.

Die IBKR Web API, früher Client Portal Web API, arbeitet über HTTP und hat ein eigenes Limit-System. Global gelten 10 Anfragen pro Sekunde je angemeldetem Benutzernamen, also je Web-API-Sitzung. Bei Überschreitung antwortet der Server mit dem HTTP-Status 429 Too Many Requests. Verstöße treffen die IP-Adresse: Sie kann laut aktueller Doku für 10 Minuten in eine „Penalty Box“ kommen (die ältere v1-Doku nennt 15 Minuten) und bei wiederholten Verstößen dauerhaft gesperrt werden, bis das Problem behoben ist.

Zusätzlich haben einzelne Endpunkte eigene, oft viel engere Grenzen. Eine Auswahl:

Die Tabelle erklärt einen typischen Fehler: Ein Bot fragt jede Sekunde die Orderliste ab, um den Status zu prüfen, und bekommt nach kurzer Zeit nur noch 429. Für laufende Updates bietet die Web API einen Websocket mit abonnierbaren Themen; REST-Abfragen eignen sich für den gelegentlichen Abgleich. Die Scanner-Parameter ändern sich selten und gehören in einen Zwischenspeicher. Die Grenze für den Endpunkt mit historischen Daten hat IBKR laut Changelog am 9. September 2026 neu gefasst: 10 pro Sekunde beziehungsweise 50 pro Minute. Wer schneller lädt, bekommt HTTP 429.

Der Flex Web Service, über den sich vorher im Client Portal angelegte Berichte wie Trades oder Kontoauszüge abrufen lassen, ist noch strenger: Laut Fehlerliste sind je Token 1 Anfrage pro Sekunde und höchstens 10 pro Minute erlaubt, etwa an SendRequest. Darüber kommt Flex-Fehler 1018. Fehler 1019 bedeutet dagegen, dass der Bericht noch erstellt wird. Hier hilft Warten mit festem Abstand, nicht schnelleres Nachfragen. Die Fehlerliste nennt außerdem Fehler 1025 für zu viele Fehlversuche.

Drosseln in Python: das Token-Bucket-Muster.

Ein Token Bucket (Eimer mit Wertmarken) ist das Standardmuster, um Anfragen gleichmäßig zu verteilen. Der Eimer füllt sich mit einer festen Rate, etwa acht Marken pro Sekunde, und fasst höchstens eine bestimmte Menge. Jede Anfrage nimmt eine Marke heraus. Ist der Eimer leer, wartet die Anfrage, bis wieder eine Marke da ist. Kurze Spitzen sind bis zur Eimergröße erlaubt, im Mittel bleibt die Rate eingehalten.

Für IBKR sollten Sie je Limit einen eigenen Eimer anlegen, nicht einen für alles. Die folgende Klasse arbeitet mit asyncio und passt damit zu ib_async und zu asynchronen HTTP-Clients wie httpx. Wie Event-Loop und nebenläufige Aufgaben in einem Bot zusammenspielen, erklärt der Artikel zu asyncio für Trading-Bots.

import asyncio
import time


class TokenBucket:
    """Token-Bucket: rate Marken pro Sekunde, höchstens capacity auf Vorrat."""

    def __init__(self, rate: float, capacity: float):
        self.rate = rate
        self.capacity = capacity
        self.tokens = float(capacity)
        self.updated = time.monotonic()
        self.lock = asyncio.Lock()

    async def acquire(self, cost: float = 1.0) -> None:
        if cost > self.capacity:
            raise ValueError("cost größer als capacity: würde ewig warten")
        async with self.lock:          # Wartende kommen der Reihe nach dran
            while True:
                now = time.monotonic()
                self.tokens = min(self.capacity,
                                  self.tokens + (now - self.updated) * self.rate)
                self.updated = now
                if self.tokens >= cost:
                    self.tokens -= cost
                    return
                await asyncio.sleep((cost - self.tokens) / self.rate)

Angewendet auf die Limits von oben ergeben sich zum Beispiel diese Eimer. Der Code ist ein Gerüst für Tests mit dem Paper-Account, kein fertiges Produktivsystem:

# Grenzen laut IBKR-Doku (Stand Oktober 2026), jeweils mit Puffer
hist_small = TokenBucket(rate=1 / 11, capacity=2)  # Bars bis 30 s: max. 60 in 10 Min.
web_global = TokenBucket(rate=8, capacity=8)       # Web API: 10 pro Sekunde je Sitzung
web_hist = TokenBucket(rate=0.7, capacity=1)       # /iserver/marketdata/history: 50 pro Minute


async def lade_kerzen(ib, contract, what="TRADES"):
    """TWS API über ib_async (drosselt die Grundregel bereits selbst)."""
    await hist_small.acquire(cost=2 if what == "BID_ASK" else 1)  # BID_ASK zählt doppelt
    return await ib.reqHistoricalDataAsync(
        contract, endDateTime="", durationStr="1800 S",
        barSizeSetting="30 secs", whatToShow=what, useRTH=True)


async def web_historie(client, base_url, conid):
    """Web API über httpx.AsyncClient, mit Rückzug bei HTTP 429."""
    for versuch in range(3):
        await web_hist.acquire()
        await web_global.acquire()
        r = await client.get(f"{base_url}/iserver/marketdata/history",
                             params={"conid": conid, "period": "1d", "bar": "5min"})
        if r.status_code != 429:
            r.raise_for_status()
            return r.json()
        await asyncio.sleep(10 * 2 ** versuch)     # 10, 20, 40 Sekunden
    raise RuntimeError("Weiter HTTP 429: Bot pausieren und Ursache prüfen")

Drei Details entscheiden, ob das Muster in der Praxis trägt. Erstens die Eimergröße: Bei der Historie-Regel sorgt ein kleiner Eimer dafür, dass auch nach einer Pause kein Schwall von Anfragen entsteht. Ein Eimer mit 60 Marken würde nach zehn Minuten Ruhe alle auf einmal freigeben, mit den nachlaufenden Marken wären dann mehr als 60 Anfragen in zehn Minuten möglich. Zweitens identische Anfragen: Die 15-Sekunden-Regel löst kein Eimer, sondern ein Zwischenspeicher, der gleiche Anfragen erkennt und das letzte Ergebnis zurückgibt. Drittens der Puffer: Rechnen Sie mit 80 bis 90 Prozent des offiziellen Limits. Bei der Web API gilt das globale Limit zudem je Benutzername, mehrere Programme unter demselben Benutzer teilen es sich, und Eimer in getrennten Prozessen wissen nichts voneinander.

Grenzen und Risiken, auch die Order Efficiency Ratio.

Ein Token Bucket schützt vor den dokumentierten Limits, nicht vor allen Problemen. Die Zahlen stammen aus der IBKR-Dokumentation und ändern sich gelegentlich, wie die neue Grenze für historische Daten in der Web API zeigt. Halten Sie die Grenzen deshalb als Konfiguration vor, nicht fest im Code, und prüfen Sie sie bei jedem größeren Update. Ein Bot, der wegen fehlender Daten oder einer verspäteten Stornierung falsch handelt, kann echte Verluste verursachen.

• Verbindungsabbruch im falschen Moment: Drei Verstöße im Ablehnen-Modus beenden die Sitzung. Offene Orders liegen in der Regel weiter beim Broker, der Bot sieht sie aber erst nach dem Neuverbinden wieder. Ein Abgleich von Orders und Positionen nach jedem Reconnect gehört deshalb zum Pflichtprogramm.
• Versteckte Verzögerung: Im Drosseln-Modus kann eine dringende Stornierung hinter Datenanfragen warten. Orders und Stornierungen sollten im eigenen Code Vorrang haben, Datenanfragen stellen sich hinten an.
• Datenlücken: Wird eine Historie-Anfrage abgewiesen und der Fehler nicht ausgewertet, rechnet die Strategie mit unvollständigen Daten. Ein Bot muss abgelehnte Anfragen erkennen und darf erst handeln, wenn seine Daten vollständig sind.
• Endlose Wiederholungen: Ein Bot, der bei 429 oder Fehler 162 sofort neu anfragt, verschärft das Problem. Wiederholungen brauchen wachsende Pausen und eine Obergrenze, danach einen Alarm.

Eine andere Art Grenze ist die Order Efficiency Ratio (OER). Sie ist kein Anfrage-Limit der API, sondern eine Regel von Interactive Brokers für das Orderverhalten, unabhängig von der Schnittstelle. IBKR berechnet sie aus der täglichen Orderaktivität: neue Orders plus Änderungen plus Stornierungen, geteilt durch die ausgeführten Orders plus eins. Ein Wert über 20 gilt laut IBKR in der Regel als exzessiv. Wer regelmäßig darüber liegt, wird benachrichtigt; wer nicht reagiert oder einen besonders hohen Wert erreicht, muss mit Handelsbeschränkungen rechnen. Gemeint sind laut IBKR vor allem automatisierte Systeme, die Tausende Orders senden, von denen kaum eine ausgeführt wird. IBKR empfiehlt unter anderem, Orders zu ändern statt zu stornieren und neu zu senden: Eine Änderung zählt einmal, Stornieren plus Neusenden zweimal.

Was Sie jetzt konkret tun können.

1. Marktdatenlinien Ihres Kontos prüfen und daraus das Grundlimit berechnen: Linien geteilt durch 2 pro Sekunde.
2. In TWS oder IB Gateway unter Global Configuration, API, Settings die Pacing-Option bewusst setzen und festhalten, welche Einstellung gilt.
3. Alle Stellen im Code suchen, die Anfragen stellen, und jede einem Limit zuordnen: Grundregel, Historie, Tick-by-Tick, Markttiefe, Web-API-Endpunkt oder Flex.
4. Je Limit einen Token Bucket mit 80 bis 90 Prozent der offiziellen Rate einrichten und Orders vor Datenanfragen bevorzugen.
5. Fehler 100, 162 und 420, HTTP 429 und Flex-Fehler 1018 gezielt protokollieren, alarmieren und danach automatisch langsamer werden.
6. Den Start des Bots im Paper-Account mit der vollen Symbolliste testen und messen, wie lange das Laden der Daten tatsächlich dauert.
7. Bei Systemen mit vielen Orderänderungen die Order Efficiency Ratio täglich mitschreiben.

Wenn Sie ein System für Interactive Brokers entwickeln lassen oder einen bestehenden Bot stabilisieren wollen: Marcel Gautsche entwickelt Python-Systeme für IBKR nach Ihren Vorgaben, mit Drosselung, Fehlerbehandlung und auf Wunsch Betrieb auf einem VPS mit Monitoring. Die Live-Aktivierung auf Ihrem Konto übernehmen Sie selbst.

Häufige Fragen.

Wie viele Anfragen pro Sekunde erlaubt die Interactive Brokers API?

Die TWS API erlaubt so viele Anfragen pro Sekunde, wie das Konto Marktdatenlinien hat, geteilt durch 2. Mit den standardmäßigen 100 Linien sind das 50 Anfragen pro Sekunde, mit 200 Linien 100. Für die Web API gilt dagegen ein globales Limit von 10 Anfragen pro Sekunde je Sitzung, einzelne Endpunkte sind noch enger begrenzt. Stand Oktober 2026 laut IBKR-Dokumentation.

Was bedeutet Fehler 100 bei Interactive Brokers?

Fehler 100 heißt, dass Ihr Programm mehr Nachrichten pro Sekunde geschickt hat als erlaubt. Er erscheint, wenn in TWS oder IB Gateway die Option zum Ablehnen von Nachrichten oberhalb der maximalen Rate aktiv ist. Nach drei Verstößen beendet TWS die API-Sitzung. Abhilfe schaffen eine eigene Drosselung im Code, etwa per Token Bucket, und die Suche nach Schleifen, die unnötig viele Anfragen stellen.

Was ist eine Pacing Violation bei historischen Daten von IBKR?

Bei historischen Bars bis 30 Sekunden liegt ein Verstoß vor, wenn Sie eine identische Anfrage innerhalb von 15 Sekunden wiederholen, sechs oder mehr Anfragen für denselben Kontrakt, dieselbe Börse und denselben Tick-Typ in zwei Sekunden stellen oder mehr als 60 Anfragen in zehn Minuten. BID_ASK zählt doppelt. Die Meldung kommt in der Regel als Fehler 162, dessen Text die Pacing Violation nennt.

Was tun bei HTTP 429 in der IBKR Web API?

HTTP 429 bedeutet, dass das globale Limit von 10 Anfragen pro Sekunde je Sitzung oder ein Endpunktlimit überschritten wurde. Stoppen Sie die Anfragen, warten Sie mit wachsendem Abstand und drosseln Sie danach dauerhaft. Verstöße können die IP-Adresse laut IBKR für 10 Minuten in eine Penalty Box bringen (ältere Doku: 15 Minuten), im Wiederholungsfall droht eine dauerhafte Sperre, bis das Problem behoben ist.

Drosselt ib_async Anfragen an Interactive Brokers automatisch?

Ja, der Client von ib_async begrenzt ausgehende Nachrichten standardmäßig auf 45 pro Sekunde, einstellbar über MaxRequests und RequestsInterval. Das deckt die Grundregel bei 100 Marktdatenlinien ab, nicht aber die Sonderlimits für historische Daten, Tick-by-Tick oder Markttiefe. Diese Grenzen müssen Sie im eigenen Code beachten, etwa mit einem eigenen Token Bucket je Limit.

Quellen und Stand.

• Pacing Limitations: Introduction (TWS API) — Interactive Brokers
• Pacing Behavior (TWS API) — Interactive Brokers
• Market Data: Historical Data Limitations, Pacing Violations for Small Bars (TWS API) — Interactive Brokers
• Specialized Market Data Lines — Interactive Brokers
• Web API: Pacing Limitations — Interactive Brokers
• Flex Web Service: Error Codes (1018, 1019, 1025) — Interactive Brokers
• Order Management Overview (Order Efficiency Ratio) — Interactive Brokers FAQ
• ib_async: client.py (Request-Drosselung) — ib-api-reloaded / GitHub

Stand: 22. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Ihr IBKR-Bot läuft in Pacing-Fehler oder Sie wollen ein System von Grund auf sauber bauen lassen? Unverbindlich anfragen — wir klären Anbindung, Drosselung, Fehlerbehandlung und den Testbetrieb im Paper-Account. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.