Interactive Brokers Web API mit Python: Sessions und Limits.

Mit der Interactive Brokers Web API steuern Sie ein IBKR-Konto per REST und Websocket aus Python, ohne die Socket-Verbindung über TWS oder IB Gateway. Privatkunden melden sich dafür über das Client Portal Gateway an, ein kleines Java-Programm auf dem eigenen Rechner, und halten die Sitzung danach mit regelmäßigen /tickle-Aufrufen am Leben. Stand Oktober 2026 gilt laut IBKR-Doku: Eine Sitzung bleibt höchstens 24 Stunden gültig, läuft ohne Anfragen nach etwa fünf bis sechs Minuten ab, und jede Benutzer-Sitzung darf global 10 Anfragen pro Sekunde stellen. Wer mehr schickt, bekommt HTTP 429 und riskiert eine zeitweise Sperre der IP-Adresse. Dieser Artikel zeigt Schritt für Schritt, wie Login, Brokerage-Session, Keep-alive, Websocket-Streams und Limits zusammenspielen, mit einem kurzen Python-Beispiel gegen den Paper-Benutzer. Er klärt außerdem, was OAuth leistet, welche Rolle Community-Bibliotheken wie IBind spielen und wo die Web API für den Dauerbetrieb eines Trading-Bots an Grenzen stößt.

Was ist die Interactive Brokers Web API und für wen eignet sie sich?

Die Web API von Interactive Brokers (früher meist Client Portal API oder CPAPI genannt) ist eine REST-Schnittstelle: Ihr Programm schickt HTTPS-Anfragen mit JSON und bekommt JSON zurück. Für laufende Kurse, Order-Updates und Kontodaten gibt es zusätzlich einen Websocket, also eine dauerhaft offene Verbindung, über die der Server von sich aus Nachrichten schickt. IBKR teilt die Web API in zwei Bereiche: Account Management für Advisors und Introducing Broker sowie Trading. Der Trading-Teil steht laut IBKR allen Kunden kostenlos zur Verfügung. Voraussetzung ist ein vollständig eröffnetes und finanziertes Live-Konto vom Typ IBKR Pro, auch wenn Sie nur mit dem zugehörigen Paper-Konto arbeiten.

Der Unterschied zur klassischen TWS API liegt vor allem im Transport. Die TWS API spricht über einen TCP-Socket mit einer laufenden TWS oder einem IB Gateway, die Web API über HTTP mit dem Client Portal Gateway oder direkt mit den Servern von IBKR. Für Python bedeutet das: Sie brauchen keine spezielle Bibliothek, requests und ein Websocket-Client reichen. Wie die Socket-Variante in Python aussieht, beschreibt der Artikel Interactive Brokers API mit Python: Praxis-Leitfaden.

Gut geeignet ist die Web API für Werkzeuge, die Kontostände, Positionen und Orders überwachen, für Dashboards, für Order-Automatisierung mit moderater Frequenz und für Umgebungen, in denen HTTP einfacher zu betreiben ist als ein Socket-Client. Weniger geeignet ist sie, wenn ein System unbeaufsichtigt über viele Tage laufen soll, viele Marktdaten-Abfragen pro Sekunde braucht oder keinen menschlichen Login verträgt.

Login über das Client Portal Gateway: so funktioniert die Sitzung.

Für Einzelkonten ist das Client Portal Gateway der dokumentierte Weg. Es ist ein Java-Programm, das Sie herunterladen, entpacken und mit bin\run.bat root\conf.yaml (Windows) starten. Anschließend öffnen Sie im Browser https://localhost:5000 und melden sich mit Ihren IBKR-Zugangsdaten an, beim Live-Benutzer in der Regel mit Zwei-Faktor-Bestätigung. Das Gateway leitet danach Ihre lokalen API-Anfragen authentifiziert an IBKR weiter. IBKR nennt zwei harte Einschränkungen: Der Login muss im Browser auf demselben Rechner erfolgen, auf dem das Gateway läuft, und alle API-Aufrufe müssen von diesem Rechner kommen. Endpunkte, die mit /gw/api, /oauth oder /oauth2 beginnen, funktionieren über das Gateway nicht.

Zwei praktische Details fallen beim ersten Start auf. Erstens bringt das Gateway laut IBKR kein gültiges TLS-Zertifikat mit, deshalb warnen Browser und Python vor der Verbindung. Betroffen ist nur die lokale Strecke, die Verbindung zu IBKR bleibt verschlüsselt. Im lokalen Test wird die Zertifikatsprüfung oft abgeschaltet; IBKR weist darauf hin, dass Nutzer für die localhost-Verbindung selbst ein Zertifikat signieren können. Zweitens ist Port 5000 laut IBKR vor allem auf Macs häufig belegt; dann ändern Sie listenPort in der Datei root/conf.yaml, üblich ist zum Beispiel 5001.

Wichtig ist das Sitzungsmodell. IBKR beschreibt die Web-API-Sitzung als zweistufig:

• Read-only-Sitzung: die äußere Ebene, Voraussetzung für jede Anfrage. Sie erlaubt nur Endpunkte außerhalb von /iserver, etwa Portfolio-Daten und bestimmte Instrumentensuchen.
• Brokerage-Session: die innere Ebene für alles hinter /iserver, also Orders, Marktdaten und Handelsfunktionen.

Ein Benutzername kann über alle IBKR-Plattformen hinweg nur eine Brokerage-Session gleichzeitig haben. Melden Sie sich mit demselben Benutzer in TWS, IBKR Mobile oder im Client Portal an, konkurriert diese Sitzung mit Ihrem Python-Programm. IBKR empfiehlt für parallele Nutzung einen zweiten Benutzernamen. Beachten Sie dabei: Marktdaten-Abos gelten pro Benutzer, und jeder abonnierte Benutzer zahlt die Gebühren separat.

Init, Tickle und Ablauf der Sitzung (mit Python-Beispiel).

Nach dem Browser-Login prüfen Sie mit /iserver/auth/status, ob die Brokerage-Session steht. Die Antwort enthält unter anderem connected (Verbindung zum Backend) und authenticated (Brokerage-Session aktiv). Steht connected auf true und authenticated auf false, ist die Brokerage-Session abgelaufen, die Verbindung aber noch da. Dann eröffnet POST /iserver/auth/ssodh/init eine neue Brokerage-Session. Ist auch connected false, ist in der Regel ein neuer Login im Browser nötig.

IBKR beschreibt für den Start einer Brokerage-Session eine feste Reihenfolge:

1. POST /iserver/auth/ssodh/init mit publish und compete auf true. compete trennt dabei konkurrierende Brokerage-Sessions desselben Benutzers.
2. 2 Sekunden warten, bevor weitere /iserver-Anfragen folgen.
3. GET /iserver/accounts abrufen und prüfen, dass die Antwort nicht leer ist. Erst dann ist die Sitzung einsatzbereit.
4. Optional, von IBKR ausdrücklich empfohlen, wenn Orders folgen: Bestätigungsdialoge über /iserver/questions/suppress vorab unterdrücken.

Danach geht es um das Wachhalten. Eine Brokerage-Session endet, wenn etwa fünf Minuten keine Anfrage kommt; die FAQ spricht von rund sechs Minuten. IBKR empfiehlt, /tickle etwa jede Minute aufzurufen. Jede andere /iserver-Anfrage und offene Marktdaten-Streams halten die Sitzung ebenfalls aktiv. Unabhängig davon bleibt eine Sitzung höchstens 24 Stunden authentifiziert. Der Reset erfolgt um Mitternacht nach der Zeit von New York, Zug oder Hongkong, je nach nächstgelegenem Server. Hinzu kommt eine tägliche Wartung der /iserver-Funktionen: laut aktueller Doku gegen 01:00 Uhr Ortszeit der Region (für Europa als 01:00 CEST angegeben), die übrige Web API wird nur samstagabends gewartet. IBKR rät, die Sitzung nach der Wartung zu trennen und das Gateway neu zu starten.

Das folgende Beispiel bildet diesen Ablauf mit requests ab. Es setzt einen laufenden, im Browser angemeldeten Gateway mit Ihrem Paper-Benutzer voraus und platziert keine Orders.

import time
import requests
import urllib3

# Nur Paper-Benutzer! Das Gateway bringt kein gültiges Zertifikat mit,
# deshalb hier im lokalen Test ohne Zertifikatsprüfung.
urllib3.disable_warnings()
BASE = "https://localhost:5000/v1/api"
s = requests.Session()
s.verify = False

def call(method, path, **kw):
    for attempt in range(4):
        r = s.request(method, BASE + path, timeout=15, **kw)
        if r.status_code != 429:
            r.raise_for_status()
            return r.json()
        time.sleep(2 ** attempt)        # zurückhaltend warten
    raise RuntimeError("Wiederholt HTTP 429: Abfragetakt prüfen")

def ensure_brokerage_session():
    st = call("POST", "/iserver/auth/status")
    if not st.get("connected"):
        raise RuntimeError("Keine Verbindung: im Browser neu anmelden")
    if not st.get("authenticated"):
        call("POST", "/iserver/auth/ssodh/init",
             json={"publish": True, "compete": True})
        time.sleep(2)                   # 2 Sekunden Pause laut IBKR
    accounts = call("GET", "/iserver/accounts").get("accounts", [])
    if not accounts:
        raise RuntimeError("Konto-Liste leer: Sitzung nicht bereit")
    return accounts

print("Konten:", ensure_brokerage_session())
while True:
    t = call("POST", "/tickle")
    auth = t.get("iserver", {}).get("authStatus", {})
    if not auth.get("authenticated"):
        ensure_brokerage_session()
    time.sleep(60)                      # Tickle etwa jede Minute

In einem echten System gehören Protokollierung, eine Alarmierung bei abgelaufener Anmeldung, ein Neustart des Gateways nach der nächtlichen Wartung und eine Ratenbegrenzung über alle Programmteile hinweg dazu. Die Methoden folgen der aktuellen API-Referenz, die /tickle und /iserver/auth/status als POST führt; die Pacing-Tabelle listet /tickle als GET. Prüfen Sie das Verhalten im Paper-Konto, bevor Sie sich auf eine Variante festlegen.

Websocket-Streams: warum Marktdaten-Abos erneuert werden müssen.

Für laufende Kurse ist der Websocket gedacht, nicht das wiederholte Abfragen von Snapshots. Mit dem Client Portal Gateway lautet die Adresse wss://localhost:5000/v1/api/ws. Den Sitzungsschlüssel holen Sie aus dem Feld session der /tickle-Antwort und übergeben ihn als Cookie api. Nach dem Verbindungsaufbau schickt der Server automatisch eine Nachricht mit dem Topic sts, die den Anmeldestatus meldet. Erst danach sollten Sie Abos senden. Ein Marktdaten-Abo und seine Kündigung sehen so aus (conid 265598 ist das Beispiel aus der IBKR-Doku, die Feldnummern stehen für Last, Bid, Ask und Datenstatus):

smd+265598+{"fields":["31","84","86","6509"]}
umd+265598+{}
tic

Hier hat sich 2026 am meisten geändert. Laut Web-API-Changelog enden Websocket-Marktdatenstreams mit dem Topic smd seit 14.04.2026 nach 10 Minuten; wer weiter Daten braucht, muss eine neue smd-Anfrage senden. Die am 20.10.2026 eingeführte eigene Websocket Reference formuliert es etwas anders: Streams enden nach 15 Minuten, ein neues Abo soll vor Ablauf von 10 Minuten gesendet werden. Praktisch heißt das: Erneuern Sie jedes Abo spätestens nach rund 9 Minuten und behandeln Sie fehlende Updates als Fehlerfall, nicht als ruhigen Markt.

Weitere Punkte für einen stabilen Websocket:

• Ping: Die Nachricht tic hält die Sitzung über den Websocket aktiv, empfohlen mindestens einmal pro Minute. Zusätzlich verlangt IBKR weiterhin regelmäßige /tickle-Aufrufe über REST.
• Brokerage-Session: Marktdaten (smd), Order-Updates (sor), Trades (str) und Benachrichtigungen (ntf) brauchen eine aktive Brokerage-Session, PnL- und Kontoübersichten nicht.
• Marktdatenlinien: Wie viele Instrumente gleichzeitig laufen, bestimmt die Zahl der Marktdatenlinien Ihres Kontos.
• Datenstatus: Feld 6509 zeigt unter anderem, ob Daten in Echtzeit (R), verzögert (D), eingefroren (Z) oder gar nicht abonniert (N) ankommen. Ein Bot sollte das prüfen, bevor er mit den Kursen rechnet.

Limits und HTTP 429 sauber behandeln.

Interactive Brokers begrenzt die Web API auf 10 Anfragen pro Sekunde je authentifiziertem Benutzernamen, also je Web-API-Sitzung. Wird das Limit überschritten, antwortet die API mit 429 Too Many Requests. Laut aktueller Doku kann die IP-Adresse dann für 10 Minuten gesperrt werden; die ältere v1-Doku nennt 15 Minuten. Bei wiederholten Verstößen droht eine dauerhafte Sperre, bis das Problem behoben ist. Zusätzlich haben einzelne Endpunkte eigene, engere Grenzen (Auswahl, Stand Oktober 2026):

Die neue Doku schreibt die Order- und Trade-Endpunkte als /iserver/orders und /iserver/trades, die v1-Doku mit /account im Pfad; das Limit von einer Anfrage je fünf Sekunden ist in beiden gleich. Für Snapshots gilt seit Dezember 2025 außerdem: höchstens 100 conids und 50 Felder pro Abfrage.

Für ein Python-Programm folgen daraus drei Regeln. Erstens: Drosseln Sie zentral. Ein einziger Ratenbegrenzer für die gesamte Anwendung, der deutlich unter 10 Anfragen pro Sekunde bleibt, ist robuster als verstreute Pausen in einzelnen Funktionen. Zweitens: Ersetzen Sie Polling durch Streams. Orderstatus und Kurse über den Websocket zu beziehen, spart genau die Anfragen, die bei 1 je 5 Sekunden sonst schnell knapp werden. Drittens: Behandeln Sie 429 als Signal zum Bremsen, nicht als Anlass für sofortige Wiederholungen. Nach mehreren 429 in Folge sollte das Programm aufhören, Anfragen zu senden, und Sie alarmieren; eine gesperrte IP wird durch weitere Anfragen nicht schneller frei.

OAuth und Community-Clients: was offiziell ist.

Neben dem Gateway kennt die Web API zwei OAuth-Verfahren, mit denen Anfragen direkt an https://api.ibkr.com gehen, ohne lokales Gateway und ohne Browser-Login. OAuth 1.0a ist laut IBKR für Advisor-, Broker-, Prop-Trading-Gruppen-, Fonds- und institutionelle Konten vorgesehen und die einzige unterstützte Methode für Drittanbieter-Software. OAuth 2.0 ist auf der Seite für Organisationen als Beta gekennzeichnet und bietet zusätzlich Zugriff auf Account-Management-Funktionen. Für Einzelkonten dokumentiert IBKR das Client Portal Gateway. Drittanbieter, die Software für fremde Konten anbieten wollen, durchlaufen bei IBKR ein Onboarding mit Compliance-Prüfung.

In der Community gibt es Python-Bibliotheken, die die Web API bequemer machen. Ein verbreitetes Beispiel ist IBind, ein REST- und Websocket-Client für die Client Portal Web API mit OAuth-1.0a-Unterstützung; Version 0.2.2 erschien am 06.10.2026 auf PyPI. Das Projekt stellt selbst klar, dass es nicht von Interactive Brokers gebaut, gepflegt oder befürwortet wird. Nutzer berichten, dass OAuth 1.0a auch für Einzelkonten funktioniere. Offiziell zugesichert ist das nicht, und das kann sich ohne Ankündigung ändern. Das Schwesterprojekt IBeam hält das Gateway per Browser-Automatisierung angemeldet, was eine weitere inoffizielle Komponente in die Kette bringt.

Community-Bibliotheken sparen Arbeit, verschieben aber die Verantwortung. Prüfen Sie Version, Pflegezustand und offene Fehlerberichte, fixieren Sie die Version in Ihrem Projekt und kapseln Sie die Bibliothek so, dass ein Wechsel zu direkten requests-Aufrufen möglich bleibt.

Grenzen und Risiken der Web API.

Die Web API ist für viele Automatisierungen brauchbar, hat aber Eigenschaften, die Sie vor dem Projektstart kennen sollten:

• Menschlicher Login: Mit dem Gateway braucht jede neue Sitzung einen Browser-Login, beim Live-Benutzer in der Regel mit Zwei-Faktor-Bestätigung, spätestens nach 24 Stunden und teils schon nach der nächtlichen Wartung. Eine automatisierte Anmeldung am Gateway unterstützt IBKR nicht; Umgehungen per Browser-Steuerung sind inoffiziell und können Sicherheitsrisiken schaffen.
• Konkurrierende Sitzungen: Ein Login mit demselben Benutzer in TWS oder der Mobile-App kann die Brokerage-Session Ihres Programms beenden, und umgekehrt trennt compete andere Sitzungen.
• Zeitliche Lücken: Tägliche Wartung, Mitternachts-Reset und das Ende der Marktdatenstreams erzeugen Phasen ohne Daten oder ohne Handelsfunktion. Ein Bot muss solche Lücken erkennen und darf in ihnen nicht auf veralteten Kursen handeln.
• Bestätigungsdialoge: Orders lösen teils Rückfragen aus, etwa bei Preisabweichungen. Werden sie pauschal unterdrückt, fallen auch Warnungen weg, die Fehler abfangen würden. Seit 07.10.2026 dokumentiert IBKR zudem Server-Prompts mit mehr als einer Ja-Nein-Wahl; deren Kennung kommt nur über den Websocket, der deshalb schon vor dem Absenden der Order laufen muss.
• Lokale Angriffsfläche: Das angemeldete Gateway nimmt Anfragen von dem Rechner an, auf dem es läuft. Jedes Programm auf diesem Rechner kann damit potenziell auf Ihr Konto zugreifen. Ein eigener Benutzer, eine gehärtete Maschine und kein offener Port nach außen gehören deshalb dazu.
• Paper ist nicht Live: Das Paper-Konto ist eine Simulation. Es zeigt, ob Ihr Code technisch funktioniert, nicht, wie Orders im echten Markt gefüllt werden.

Das größte Risiko bleibt die eigene Logik. Ein Fehler in Ordergröße, Wiederholungslogik oder Positionsabgleich kann im Live-Konto schnell echte Verluste verursachen, bei Hebelprodukten auch über den Einsatz hinaus. Automatisierung verbessert keine Strategie; sie führt aus, was programmiert ist, auch das Falsche. Unabhängige Schutzmechanismen wie Positionslimits, ein Not-Aus und Alarme gehören deshalb zu jedem System, bevor es mit echtem Geld läuft.

So starten Sie mit dem Paper-Benutzer.

Die Web API kennt keinen Umschalter zwischen Live und Paper. Sie melden sich mit dem eigenen Paper-Benutzernamen an, den Sie im Client Portal unter Einstellungen, Bereich „Paper Trading Account“ finden; dort lässt sich auch ein separates Paper-Passwort setzen. So gehen Sie vor:

1. Prüfen Sie, dass Ihr Live-Konto eröffnet, finanziert und vom Typ IBKR Pro ist, und notieren Sie den Paper-Benutzernamen.
2. Installieren Sie Java, laden Sie das Client Portal Gateway herunter und starten Sie es. Melden Sie sich unter https://localhost:5000 mit dem Paper-Benutzer an.
3. Rufen Sie /iserver/auth/status und /iserver/accounts auf und führen Sie das Python-Beispiel aus. Lassen Sie es über eine Nacht laufen und protokollieren Sie, wann die Sitzung abbricht.
4. Öffnen Sie einen Websocket, abonnieren Sie ein Instrument und prüfen Sie, ob Ihr Code das Ende des Streams erkennt und rechtzeitig erneuert.
5. Bauen Sie den zentralen Ratenbegrenzer ein und testen Sie bewusst, wie Ihr Programm auf HTTP 429 reagiert, ohne die Grenzen auszureizen.
6. Entscheiden Sie erst danach, ob die Web API für Ihren Anwendungsfall trägt oder ob TWS API mit IB Gateway besser passt. Für den Dauerbetrieb des Gateways lohnt der Blick in IB Gateway im Dauerbetrieb.

Wenn ich Trading-Systeme für Interactive Brokers entwickle, gehören Sitzungsabbrüche, Wartungsfenster und Limits in den Test mit dem Paper-Konto, damit sie nicht erst im Live-Betrieb auffallen. Die Live-Aktivierung erfolgt anschließend durch den Kontoinhaber selbst.

Häufige Fragen.

Brauche ich für die Interactive Brokers Web API die TWS?

Nein. Die Web API arbeitet ohne TWS und ohne IB Gateway. Privatkunden brauchen stattdessen das Client Portal Gateway, ein kleines Java-Programm, über das sie sich im Browser auf demselben Rechner anmelden. Organisationen können mit OAuth direkt die Server von IBKR ansprechen. Voraussetzung ist laut IBKR ein eröffnetes, finanziertes IBKR-Pro-Konto, auch für den Test mit dem Paper-Konto.

Wie oft muss ich tickle bei der IBKR Web API aufrufen?

IBKR empfiehlt, den Endpunkt tickle etwa jede Minute aufzurufen. Ohne Anfragen läuft die Brokerage-Session nach rund fünf bis sechs Minuten ab. Andere iserver-Anfragen und offene Marktdatenstreams halten die Sitzung ebenfalls aktiv. Unabhängig vom Keep-alive endet die Authentifizierung spätestens nach 24 Stunden, und die tägliche Wartung kann die Sitzung früher trennen.

Was bedeutet HTTP 429 bei der IBKR Web API?

HTTP 429 heißt, dass Ihr Programm zu viele Anfragen geschickt hat. Global gelten 10 Anfragen pro Sekunde je Benutzer-Sitzung, einzelne Endpunkte haben engere Limits, etwa eine Anfrage je fünf Sekunden für die Orderliste. Bei Verstößen kann die IP-Adresse laut aktueller Doku zehn Minuten gesperrt werden. Das Programm sollte dann pausieren und alarmieren, statt sofort zu wiederholen.

Kann ich die IBKR Web API ohne täglichen Login automatisieren?

Mit dem Client Portal Gateway offiziell nicht: Jede neue Sitzung braucht einen Browser-Login, und die Authentifizierung endet spätestens nach 24 Stunden. Vollautomatische Anmeldung per OAuth dokumentiert IBKR für Organisationen und Drittanbieter. Community-Projekte wie IBind berichten, dass OAuth 1.0a auch für Einzelkonten funktioniert, offiziell zugesichert ist das aber nicht.

Ist IBind eine offizielle Bibliothek von Interactive Brokers?

Nein. IBind ist ein Community-Projekt, ein Python-Client für REST und Websocket der Client Portal Web API mit OAuth-1.0a-Unterstützung. Das Projekt erklärt selbst, dass es nicht von Interactive Brokers gebaut, gepflegt oder befürwortet wird. Version 0.2.2 erschien am 06.10.2026. Wer es einsetzt, sollte die Version fixieren und den Pflegezustand regelmäßig prüfen.

Quellen und Stand.

• Trading Sessions in the Web API — Interactive Brokers
• Authentication Frequently Asked Questions — Interactive Brokers
• Limitations of the Client Portal Gateway — Interactive Brokers
• Pacing Limitations (Web API) — Interactive Brokers
• Web API Changelog — Interactive Brokers
• Streaming Market Data (Websocket Reference) — Interactive Brokers
• Web API Authentication: Introduction — Interactive Brokers
• ibind 0.2.2 — PyPI

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

Sie wollen ein Python-System für die IBKR Web API entwickeln und stabil betreiben lassen? Unverbindlich anfragen — wir klären Sitzungsführung, Limits, Tests im Paper-Konto und den Betrieb mit Monitoring. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.