IBKR-API-Fehlercodes: was Ihr Bot tun muss.

Ein Interactive Brokers API Fehlercode bedeutet nicht automatisch, dass etwas kaputt ist: Die TWS API meldet echte Fehler und reine Statusinformationen über denselben Callback error(). Ihr Bot muss jeden Code deshalb einer Gruppe zuordnen und passend reagieren, also 2104, 2106 und 2158 nur protokollieren, bei 1100 keine neuen Orders senden, nach 1101 die Marktdaten neu abonnieren und bei 502 oder 326 die Verbindungsparameter prüfen statt endlos neu zu verbinden. Dieser Artikel liefert eine Triage-Tabelle für die häufigsten Codes aus Verbindung, Marktdaten, Orders und Systembetrieb. Er erklärt den täglichen Server-Reset, die Reconnect-Logik und das Risiko der Einstellung „Maintain and resubmit orders“ und zeigt ein Logging-Muster in Python. Stand Oktober 2026, geprüft an der IBKR-Dokumentation einschließlich der am 24.09.2026 ergänzten Codes 0 und 10213. Codes und Meldungstexte können sich mit neuen TWS-Versionen ändern.

Wie meldet die TWS API Fehler und Informationen?

Die TWS API hat keinen getrennten Kanal für Warnungen. Laut IBKR antwortet TWS auf fast jede Anfrage entweder mit den angeforderten Daten oder mit einer Meldung an EWrapper.error(). Derselbe Callback transportiert echte Fehler, Warnungen und Benachrichtigungen, die ausdrücklich nicht bedeuten, dass etwas falsch läuft. Wer jede Meldung als Abbruchgrund behandelt, legt seinen Bot schon beim Start lahm.

Der Callback liefert fünf Werte:

• reqId: die Kennung der zugehörigen Anfrage; ib_async nutzt sie bei Orderfehlern als Order-ID. Meldungen ohne Anfragebezug, etwa zu den Datenfarmen, kommen in der Praxis mit -1.
• errorTime: der Unix-Zeitstempel des Fehlers, erst ab TWS API 10.33.
• errorCode: der Code, auf den Ihre Logik verzweigt.
• errorString: der Text, fürs Log, nicht für Verzweigungen.
• advancedOrderRejectJson: bei abgelehnten Orders eine ausführlichere Begründung im JSON-Format.

Die Erweiterung um errorTime ist ein typischer Stolperstein: Ein eigener Python-Handler mit der alten Signatur passt nicht zur neuen ibapi-Version: Die Werte landen in falschen Parametern oder der Aufruf scheitert, und Meldungen gehen verloren. Prüfen Sie die Signatur bei jedem API-Update.

Bibliotheken nehmen Ihnen einen Teil der Einordnung ab. ib_async wertet zum Beispiel alle Codes von 2100 bis 2199 sowie einige weitere wie 110, 321 und 404 als Warnung und lässt die zugehörige Order bestehen (110 nicht bei neuen Orders); andere Fehler zu einer offenen Order markiert die Bibliothek als storniert. Das ersetzt nicht die eigene Entscheidung, bei welchen Codes Ihr System anhält.

IBKR-API-Fehlercodes im Überblick: Bedeutung und Reaktion.

Die Tabelle ordnet typische Codes aus Bot-Logs nach Dringlichkeit. Datenfarmen sind die Server von IBKR für Kurse, Historie und Kontraktdaten. Die Bedeutung stammt aus den IBKR-Seiten „Error Codes“ und „System Message Codes“. Die Spalte Reaktion beschreibt eine sinnvolle Grundeinstellung für automatisierte Systeme, keine Vorgabe von IBKR.

Die Liste ist eine Auswahl. Jeder Code, der nicht in Ihrer Tabelle steht, sollte als Fehler mit Alarm gelten, bis er analysiert ist.

Verbindungsfehler: 502, 326 und 1100 bis 1102.

502 „Couldn't connect to TWS“ entsteht, bevor TWS überhaupt beteiligt ist. Kann das Betriebssystem keinen TCP-Socket zu Adresse und Port öffnen, meldet es den Fehler, und die API reicht ihn als 502 weiter. Deshalb steht er nicht in den TWS-Logs. Prüfen Sie der Reihe nach: Läuft TWS oder IB Gateway und ist angemeldet? Ist „Enable ActiveX and Socket Clients“ aktiv? Stimmt der Port mit dem „Socket Port“ in den API-Einstellungen überein? Standard sind 7496 und 7497 (live, paper) bei TWS sowie 4001 und 4002 bei IB Gateway. Bei Verbindungen über das Netz kommen Firewall, Virenscanner und die Liste „Trusted IPs“ hinzu, in der nur einzelne Adressen stehen dürfen.

326 „client id is already in use“ heißt, dass bereits eine Anwendung mit derselben Client-ID verbunden ist. Pro TWS-Sitzung sind bis zu 32 Clients möglich, jeder braucht eine eigene ID. Typisch ist ein nach einem Absturz weiterlaufender Prozess. Die naheliegende Automatik, bei 326 einfach die ID hochzuzählen, ist gefährlich: Dann laufen womöglich zwei Instanzen derselben Strategie parallel und senden doppelte Orders. Besser ist eine feste, dokumentierte ID je Komponente und bei 326 ein Alarm mit Prüfung, welcher Prozess die ID hält.

504 „Not connected“ kommt, wenn Ihr Code ohne Verbindung sendet. IBKR nennt nextValidId als Signal, dass die Verbindung steht; Aufrufe davor können verworfen werden.

1100, 1101 und 1102 betreffen nicht Ihren Socket, sondern die Verbindung zwischen TWS und den IB-Servern. Laut IBKR entsteht 1100 durch Internetprobleme, den nächtlichen Server-Reset oder eine konkurrierende Sitzung. TWS verbindet sich danach selbst neu. Kommt 1101, sind Ihre Marktdaten-Anfragen verloren und müssen neu gesendet werden. Bei 1102 bleiben sie erhalten. In beiden Fällen sollte der Bot Orders, Ausführungen und Positionen abgleichen, bevor er wieder handelt.

Marktdaten-Meldungen: 2104, 354, 10089, 10197.

2104 „Market data farm connection is OK“, 2106 für die Farm historischer Daten und 2158 für die Kontraktdefinitionen sind laut IBKR ausdrücklich keine echten Fehler, sondern erwartete Benachrichtigungen beim Verbindungsaufbau. 2107 und 2108 melden lediglich eine ruhende Farm-Verbindung. Anders 2103 und 2105: Hier ist eine Farm getrennt. Außerhalb des Server-Resets deutet das laut IBKR meist auf ein Problem beim Internetanbieter hin. Ihr Bot sollte dann keine Signale auf eingefrorenen Kursen berechnen.

354 „Requested market data is not subscribed“ bedeutet, dass für das Instrument keine Live-Daten im Konto verfügbar sind. 10089 ist der feinere Fall: Das Abo existiert, deckt aber die Nutzung über die API nicht ab. Was in TWS angezeigt wird, kommt also nicht zwangsläufig über die API an. 10090 meldet ein nur teilweise vorhandenes Abo, etwa wenn bei Optionen das Abo des Basiswerts fehlt. Für Tests ohne Abo lassen sich mit reqMarketDataType(3) verzögerte Daten anfordern, die laut IBKR 15 bis 20 Minuten alt und kostenlos sind.

10197 „No market data during competing session“ tritt auf, wenn derselbe Nutzer im Paper- und im Live-Konto gleichzeitig Live-Daten anfordert; das Live-Konto hat dann Vorrang. Ähnlich wirkt eine Anmeldung im Client Portal mit demselben Benutzernamen: Sie verhindert laut IBKR den automatischen Reconnect nach dem nächsten Reset. Ein eigener Benutzername für den Bot vermeidet das.

10213 ist seit dem 24.09.2026 dokumentiert: Regulatorische Snapshots sind über die API nicht erlaubt, typischerweise weil TWS Echtzeitdaten zeigt, deren Abo für die API nicht verfügbar ist. Für alle Codes dieser Gruppe gilt: nicht in einer Schleife wiederholen, sondern das Instrument als „ohne Daten“ markieren, Alarm auslösen und dort pausieren.

Order-Fehler: 200, 201 und Rejects.

200 „No security definition has been found“ heißt, dass der Kontrakt nicht zur IBKR-Datenbank passt, meist wegen eines fehlenden oder falschen Parameters. Dieselbe Nummer kommt auch mit dem Text „ambiguous“, wenn die Angaben nicht eindeutig sind. Bei Aktien mit gleichem Symbol, gleicher Währung und Börse hilft die Primärbörse (in Python primaryExchange), bei Futures mit mehreren Multiplikatoren für denselben Verfall der multiplier. Laut IBKR genügen als Mindestangabe conId und Exchange, weil die conId einen Kontrakt eindeutig bezeichnet. Bei 200 sollte ein Bot nie raten, sondern die Order verwerfen und melden.

201 „Order rejected“ kommt von den IB-Servern. Die Begründung steht im Text und gegebenenfalls in advancedOrderRejectJson. IBKR nennt als Beispiele Größenbeschränkungen bei sehr großen Orders und Preisprüfungen, bei denen eine Order mit Status „Cancelled“ und Code 202 endet, weil der Limitpreis zu weit vom Markt entfernt ist. Weitere typische Order-Codes:

• 103: Die Order-ID ist nicht größer als eine frühere ID dieses Clients. Vergeben Sie IDs zentral, ausgehend von nextValidId.
• 110: Der Preis passt nicht zum Mindestschritt. Runden Sie auf die Tick-Größe.
• 10147 und 10148: Ein Storno scheitert, weil die Order nicht gefunden wurde oder bereits ausgeführt ist. Das ist kein harmloser Fehler, sondern ein Hinweis, dass sich Ihre Position geändert haben kann.
• 0: Ein interner Serverfehler, laut IBKR typischerweise ausgelöst durch eine Aktion, die in Ihrer Umgebung nicht verfügbar ist, zum Beispiel eine Live-exklusive Funktion im Paper-Konto.

IBKR empfiehlt, bei Orders neben error immer auch orderStatus, openOrder und execDetails auszuwerten. Ein abgelehnter oder unklarer Auftrag sollte nie automatisch neu gesendet werden. Wie ein Bot bei unklarem Status die Wahrheit beim Broker abfragt, beschreibt der Artikel zum Positionsabgleich für Trading-Bots.

Server-Reset und Reconnect sauber behandeln.

IBKR schreibt selbst, dass Sie sehr wahrscheinlich mindestens einmal am Tag die Verbindung zu den Servern verlieren, wegen der täglichen Wartung. Laut Systemstatus-Seite liegen die Reset-Fenster sonntags bis freitags in Europa bei 06:25–07:45 CET und in Nordamerika bei 00:15–01:45 ET, samstags bei 00:00–02:00 ET. Bestehende native Orders laufen weiter, Ausführungsmeldungen und simulierte Orders kommen jedoch verzögert, und IBKR rät davon ab, während der Reset-Zeiten zu handeln.

Für die Reconnect-Logik müssen Sie zwei Ebenen unterscheiden. Bei 1100 bis 1102 bleibt Ihr API-Socket offen, TWS verbindet sich selbst neu. Bricht dagegen der Socket zwischen Bot und TWS, ruft die API EWrapper.connectionClosed auf, und Ihr Bot muss selbst neu verbinden: mit wachsender Pause, Alarm nach mehreren Fehlversuchen und anschließendem Abgleich. Hinzu kommen der tägliche Neustart und die wöchentliche Neuanmeldung von TWS und IB Gateway, die im Artikel zum IB Gateway im Dauerbetrieb ausführlich behandelt werden.

Ein unterschätztes Risiko ist die Einstellung „Maintain and resubmit orders when connection is restored“. Sie ist standardmäßig aktiv. Orders, die während eines Verbindungsverlusts eingehen, speichert TWS und sendet sie automatisch, sobald die Verbindung wieder steht; schließt TWS zwischendurch, werden sie gelöscht. Für einen Bot heißt das: Eine Order, die auf Kursen von vor zehn Minuten beruht, kann nachträglich am Markt landen. Sendet der Bot nach einem Timeout selbst neu, drohen Doppelorders. Entscheiden Sie bewusst: Entweder schalten Sie die Option ab und lassen den Bot nach dem Abgleich neu entscheiden, oder Sie lassen sie an und verbieten dem Bot jedes eigene Nachsenden.

Ein schlankes Muster mit der offiziellen ibapi trennt Einordnung und Reaktion: Der Callback im EReader-Thread setzt nur Flags und füllt eine Warteschlange; Neuabonnieren und Abgleich erledigt der Hauptthread, der orders_erlaubt erst danach freigibt. Testen Sie das Muster nur mit einem Paper-Konto.

import logging
import queue
from ibapi.client import EClient
from ibapi.wrapper import EWrapper

INFO = {2104, 2106, 2107, 2108, 2158}
WARNUNG = {2103, 2105}

class Bot(EWrapper, EClient):
    def __init__(self):
        EClient.__init__(self, self)
        self.log = logging.getLogger('ibkr')
        self.orders_erlaubt = False      # erst nach Abgleich True
        self.aufgaben = queue.Queue()    # Hauptthread arbeitet ab

    def nextValidId(self, orderId):
        self.naechste_id = orderId
        self.aufgaben.put('abgleich')

    def error(self, reqId, errorTime, errorCode, errorString,
              advancedOrderRejectJson=''):
        text = f'code={errorCode} reqId={reqId} t={errorTime} {errorString}'
        if advancedOrderRejectJson:
            text += f' reject={advancedOrderRejectJson}'
        if errorCode in INFO:
            self.log.info(text)
        elif errorCode in WARNUNG:
            self.log.warning(text)
        elif errorCode in (1100, 2110):  # keine neuen Orders
            self.orders_erlaubt = False
            self.log.error(text)
        elif errorCode == 1101:
            self.aufgaben.put('neu_abonnieren')
            self.aufgaben.put('abgleich')
            self.log.warning(text)
        elif errorCode == 1102:
            self.aufgaben.put('abgleich')
            self.log.warning(text)
        else:
            self.log.error(text)         # unbekannt = Fehler + Alarm

    def connectionClosed(self):
        self.orders_erlaubt = False
        self.log.error('API-Socket geschlossen, Reconnect mit Pause')

Grenzen und Risiken automatischer Reaktionen.

Eine Fehlertabelle im Code ist nie vollständig. Die offizielle Liste umfasst mehrere Hundert Einträge, IBKR ergänzt regelmäßig Codes, wie zuletzt am 24.09.2026, und manche Nummern stehen für verschiedene Situationen, etwa 200 für einen nicht gefundenen und für einen mehrdeutigen Kontrakt. Ihre Zuordnung braucht deshalb einen klaren Standardfall: Unbekanntes informiert einen Menschen.

Automatische Reaktionen können Probleme verstärken:

• Reconnect-Schleifen ohne Pause verschleiern die Ursache, etwa einen falschen Port.
• Massenhaftes Neuabonnieren nach 1101 kann die Nachrichtenrate überschreiten. Ist in den Einstellungen das Abweisen statt Drosseln gewählt, folgt Code 100, und nach drei Verstößen beendet TWS die API-Sitzung.
• Automatisches Nachsenden nach Rejects oder Timeouts führt zu Doppelorders, besonders zusammen mit der Resubmit-Einstellung.
• Hochzählen der Client-ID bei 326 kann zwei Instanzen derselben Strategie gleichzeitig aktiv machen.
• Paper ist nicht live: Code 0 und 10197 zeigen, dass sich Paper- und Live-Umgebung unterscheiden. Ein im Paper-Konto fehlerfreier Ablauf beweist nicht, dass live alles gleich läuft.

Saubere Fehlerbehandlung senkt das Betriebsrisiko, macht eine Strategie aber nicht profitabel. Automatisierter Handel kann zu erheblichen Verlusten führen, mit Hebelprodukten auch über den Einsatz hinaus. Planen Sie unabhängig vom Bot einen manuellen Weg zum Stornieren aller Orders und einen Alarmweg, der nicht vom selben Rechner abhängt.

API-Logs aktivieren und die Fehlerbehandlung testen.

TWS und IB Gateway schreiben auf Wunsch ein eigenes API-Log mit allen ausgetauschten Nachrichten. Es ist standardmäßig aus und muss vor dem Problem aktiviert sein, sonst fehlen die entscheidenden Einträge. In TWS finden Sie die Option unter File oder Edit, Global Configuration, API, Settings, in IB Gateway unter Configure, Settings, API, Settings: „Create API message log file“ anhaken, Logging Level auf „Detail“ stellen, übernehmen. Die Dateien heißen api.[clientId].[day].log, etwa api.123.Thu.log, und liegen im Einstellungsordner, standardmäßig C:\Jts beziehungsweise IBJts unter macOS und Linux. Sie sind lokal verschlüsselt und werden über die zugehörige Sitzung entschlüsselt.

So gehen Sie jetzt vor:

1. Zählen Sie in Ihren Bot-Logs, welche Codes zuletzt aufgetreten sind.
2. Legen Sie im Code eine zentrale Zuordnung an: Info, Warnung, Handlungsbedarf, Unbekannt mit Alarm.
3. Prüfen Sie die Signatur Ihres error()-Handlers gegen die installierte ibapi-Version.
4. Provozieren Sie im Paper-Konto gezielt Fehler: falscher Port für 502, zweiter Client mit gleicher ID für 326, Netzwerk kurz trennen für 1100 und 1101, Gateway beenden für connectionClosed. Kontrollieren Sie, ob Orders gestoppt und Abos neu gesendet werden.
5. Entscheiden und dokumentieren Sie die Einstellung „Maintain and resubmit orders“.
6. Sperren Sie neue Orders in den Reset-Fenstern der Serverregion Ihres Kontos.

Wenn Sie ein bestehendes System auf diese Punkte prüfen oder ein neues Python-System für Interactive Brokers mit belastbarer Fehlerbehandlung aufbauen lassen wollen, finden Sie Details zur Entwicklung von Trading-Systemen.

Häufige Fragen.

Was bedeutet IBKR 2104 Market data farm connection is OK?

Code 2104 ist kein Fehler, sondern eine Benachrichtigung: Die Verbindung zur Marktdaten-Farm von Interactive Brokers steht. Er ist beim Verbindungsaufbau zu erwarten, ebenso 2106 für historische Daten und 2158 für Kontraktdefinitionen. Ihr Bot sollte diese Codes nur protokollieren. Aufmerksamkeit verdienen dagegen 2103 und 2105, die eine getrennte Farm melden.

Wie behebe ich IBKR Fehler 502 Couldn't connect to TWS?

Fehler 502 bedeutet, dass das Betriebssystem keinen Socket zu TWS oder IB Gateway öffnen konnte. Prüfen Sie, ob das Programm läuft und angemeldet ist, ob „Enable ActiveX and Socket Clients“ aktiv ist und ob der Port übereinstimmt, standardmäßig 7497 für TWS Paper oder 4002 für IB Gateway Paper. Bei Netzwerkverbindungen kommen Firewall und Trusted IPs hinzu.

Was tun bei IBKR Fehler 326 client id already in use?

Fehler 326 heißt, dass bereits eine Anwendung mit derselben Client-ID mit TWS verbunden ist, etwa ein nach einem Absturz weiterlaufender Prozess. Beenden Sie den alten Prozess oder vergeben Sie feste, eindeutige IDs je Komponente. Die ID automatisch hochzuzählen ist riskant, weil dann zwei Instanzen derselben Strategie parallel Orders senden können.

Was ist der Unterschied zwischen IBKR 1100, 1101 und 1102?

1100 meldet, dass TWS die Verbindung zu den IB-Servern verloren hat, etwa durch den täglichen Reset oder ein Internetproblem. 1101 meldet die Wiederherstellung mit verlorenen Marktdaten-Abos, die neu angefordert werden müssen. 1102 meldet die Wiederherstellung mit erhaltenen Daten. Nach beiden lohnt ein Abgleich von Orders und Positionen.

Was bedeutet IBKR error 200 No security definition has been found?

Der angefragte Kontrakt passt nicht zur Datenbank von Interactive Brokers, meist wegen eines falschen oder fehlenden Parameters, oder die Angaben sind mehrdeutig. Ergänzen Sie bei Aktien die Primary Exchange, bei Futures den Multiplier, oder verwenden Sie direkt conId und Exchange. Ein Bot sollte die Order bei Code 200 verwerfen und melden.

Quellen und Stand.

• Error Codes (TWS API) — Interactive Brokers
• System Message Codes (TWS API) — Interactive Brokers
• Receiving Error Messages — Interactive Brokers
• Establishing an API connection — Interactive Brokers
• TWS API Changelog 24.09.2026 — Interactive Brokers
• Current System Status: Reset Schedule — Interactive Brokers
• Intelligent Order Resubmission — Interactive Brokers
• API Logs — Interactive Brokers

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

Sie wollen Ihren IBKR-Bot robust gegen Verbindungsabbrüche und Fehlercodes machen lassen? Unverbindlich anfragen — wir klären Fehlerbehandlung, Reconnect-Logik, Tests im Paper-Konto und den Betrieb mit Monitoring. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.