IBKR Flex Web Service: Trades und Auszüge automatisch abrufen.

Mit dem Flex Web Service holen Sie Ausführungen, Kontoauszüge und Positionsdaten von Interactive Brokers per HTTP ab, ohne dass TWS oder IB Gateway laufen müssen. Sie legen dazu im Client Portal eine Flex Query als Berichtsvorlage an, erzeugen einen Token und rufen den Bericht in zwei Schritten ab: SendRequest stößt die Erstellung an, GetStatement liefert das Ergebnis. Stand Oktober 2026 gilt laut IBKR-Doku: Ein Token lässt sich mit einer Gültigkeit zwischen 6 Stunden und 1 Jahr erzeugen und auf IP-Adressen beschränken, SendRequest erlaubt 1 Anfrage pro Sekunde und höchstens 10 pro Minute, und jede Anfrage braucht einen User-Agent-Header. Dieser Artikel zeigt die Einrichtung Schritt für Schritt, ein kurzes Python-Beispiel ohne Zugangsdaten, die wichtigsten Fehlercodes als Tabelle und den Abgleich mit den Daten eines Trading-Bots am Tagesende. Steuerliche Auswertungen sind nicht Thema, es geht nur um den sauberen Datenabruf.

Hinweis: Dieser Beitrag gibt den Rechts- und Steuerstand zum unten angegebenen Datum allgemein wieder. Er ist keine Rechts- oder Steuerberatung und ersetzt nicht die Prüfung Ihres Einzelfalls durch eine Rechtsanwältin, einen Rechtsanwalt, eine Steuerberaterin oder einen Steuerberater. Alle Angaben ohne Gewähr für Vollständigkeit und Aktualität.

Was ist der Flex Web Service?

Flex Queries sind frei konfigurierbare Berichtsvorlagen im Client Portal von Interactive Brokers (IBKR). Sie legen fest, welche Abschnitte und Felder ein Bericht enthält, welchen Zeitraum er abdeckt und in welchem Format er ausgegeben wird. Es gibt zwei Arten: Activity Flex Queries bilden den Kontoauszug ab (Trades, Positionen, Cash-Bewegungen, Gebühren, Dividenden), Trade Confirmation Flex Queries enthalten die Ausführungsbestätigungen. Der Flex Web Service ist die kleine, eigenständige HTTP-Schnittstelle, mit der Sie genau diese Berichte automatisch erzeugen und abholen.

Der Unterschied zu den Handelsschnittstellen ist grundlegend. Die TWS API braucht eine laufende Trader Workstation oder ein IB Gateway, die Web API eine aktive Sitzung. Der Flex Web Service arbeitet dagegen nur mit Token und Query-ID. Laut IBKR spielen Ihre Zugangsdaten beim Abruf keine Rolle; den Benutzernamen brauchen Sie nur, um Token und Vorlagen im Client Portal zu verwalten. Damit eignet sich der Dienst gut für Aufgaben, die abseits des Handelsrechners laufen sollen:

• Trading-Journal oder Dashboard täglich mit den tatsächlichen Ausführungen füttern
• Kontoauszüge für Buchhaltung oder Archiv als XML oder CSV ablegen
• Positionen, Gebühren und Ausführungen am Tagesende mit den Aufzeichnungen eines Bots vergleichen
• Berichte für mehrere verknüpfte Konten zentral abholen

Wichtig für die Planung ist die Aktualität. In der IBKR-Doku (Fassung vom Juni 2026) heißt es: Activity-Daten werden einmal täglich zum Geschäftsschluss aktualisiert, daher bringt ein mehrmaliger Abruf am Tag nichts. Üblich ist, den Auszug des Vortags am nächsten Morgen zu holen. Trade-Confirmation-Berichte füllen sich über den Tag, eine neue Ausführung steht typischerweise nach 5 bis 10 Minuten zur Verfügung. Dort heißt es auch, dass sich der Dienst nicht für aktives Polling eignet, sondern für einen täglichen oder gelegentlichen Abruf.

Flex Query und Token im Client Portal einrichten.

Die Einrichtung geschieht einmalig von Hand im Client Portal, per API lässt sie sich nicht erledigen. Der Weg führt über Performance & Reports beziehungsweise Menü, Reporting, Flex Queries. Dort finden Sie die Bereiche Activity Flex Query, Trade Confirmation Flex Query, Zustellung und die Konfiguration des Flex Web Service.

1. Flex Query anlegen: Mit dem Plus-Symbol eine neue Activity Flex Query erstellen, Abschnitte wählen (etwa Trades, Open Positions, Cash Transactions) und darin die benötigten Felder anhaken.
2. Format und Zeitraum festlegen: Zur Wahl stehen XML, CSV, Text mit Pipe oder Tabulator. Für die Weiterverarbeitung in Python ist XML am robustesten, weil jedes Feld benannt ist. Als Zeitraum bietet IBKR unter anderem Last Business Day, Last Business Week, Last Month, Last 30 Calendar Days, Month to Date und Year to Date an.
3. Query-ID notieren: Über das Info-Symbol links neben der Query zeigt das Portal die Query-ID. Sie ist neben dem Token der zweite Wert, den Ihr Programm braucht.
4. Flex Web Service aktivieren: In der Flex-Web-Service-Konfiguration das Kästchen beim Status setzen und speichern. Danach zeigt das Portal einen Current Token.
5. Token mit Laufzeit und IP-Sperre erzeugen: Beim Erzeugen eines neuen Tokens wählen Sie eine Gültigkeit zwischen 6 Stunden und 1 Jahr und können festlegen, von welchen IP-Adressen Abrufe erlaubt sind.

Einige Details sorgen in der Praxis regelmäßig für Verwirrung. Flex-Vorlagen sind an den Benutzernamen gebunden, der sie angelegt hat. Bei verknüpften Konten ist der Token nur im Master-Konto sichtbar, kann dann aber Berichte für alle verknüpften Konten liefern, sofern die Query sie einschließt. Eine Query ist außerdem nur bei derselben Kontenauswahl sichtbar, mit der sie angelegt wurde. Bei Zeiträumen mit variabler Länge wie „Last N Days“ nimmt die API laut der älteren Doku immer die größtmögliche Zahl an Tagen, nicht den zuletzt im Portal genutzten Wert. Die Doku empfahl deshalb feste Angaben wie Last Month oder Year to Date.

Wenn Sie Orders später eindeutig zuordnen wollen, aktivieren Sie die Audit-Trail-Felder. Erst damit liefert der Bericht unter anderem Order Reference, Brokerage Order ID und Order Placement Time. Laut IBKR gibt es diese Felder derzeit nur im Live-Konto, nicht im Paper-Konto.

Bericht abrufen: SendRequest und GetStatement mit Python.

Der Abruf besteht aus zwei GET-Anfragen an https://ndcdyn.interactivebrokers.com/AccountManagement/FlexWebService. Die erste geht an /SendRequest mit drei Parametern: t ist der Token, q die Query-ID, v die Version des Dienstes. IBKR unterstützt die Versionen 2 und 3 und rät, immer 3 zu verwenden. Optional überschreiben Sie den in der Vorlage hinterlegten Zeitraum: p mit einer Zahl von Tagen (laut API-Referenz höchstens 365) oder fd und td mit Start- und Enddatum im Format JJJJMMTT. p und der Datumsbereich schließen sich aus, fd und td gehen nur gemeinsam.

Die Antwort ist ein kleines XML-Dokument. Bei Erfolg steht darin <Status>Success</Status> und ein <ReferenceCode>; das ebenfalls enthaltene Feld url ist laut IBKR ein Überbleibsel und soll ignoriert werden. Bei einem Fehler kommt Fail mit ErrorCode und ErrorMessage. Mit dem ReferenceCode als q fragen Sie dann /GetStatement ab. Je nach Größe des Berichts dauert die Erstellung unterschiedlich lang. IBKR weist darauf hin, dass zwischen beiden Anfragen eine Wartezeit nötig sein kann; solange der Bericht nicht fertig ist, meldet der Dienst Code 1019 mit der Bitte um einen späteren Versuch. Der fertige Bericht kommt direkt im gewählten Format, ein Fehler laut API-Referenz als dieselbe XML-Statusantwort.

Alle Anfragen müssen einen User-Agent-Header tragen. Das folgende Beispiel nutzt requests, liest Token und Query-ID aus Umgebungsvariablen, wartet mit wachsenden Pausen und speichert den Bericht als Datei. Es ruft nur Berichte ab und löst keine Orders aus.

import os
import time
import requests
import xml.etree.ElementTree as ET

BASE = "https://ndcdyn.interactivebrokers.com/AccountManagement/FlexWebService"
HEADERS = {"User-Agent": "flex-abruf/1.0"}      # Pflicht laut IBKR-Doku
TOKEN = os.environ["IBKR_FLEX_TOKEN"]           # nie im Code oder im Repo
QUERY_ID = os.environ["IBKR_FLEX_QUERY_ID"]
NOCHMAL = {"1001", "1004", "1005", "1006", "1007", "1008",
           "1009", "1018", "1019", "1021"}       # "bitte später erneut"

def statusantwort(text):
    """(Status, Code, Meldung) bei Statusantworten, sonst None."""
    if "<FlexStatementResponse" not in text[:300]:
        return None
    root = ET.fromstring(text)
    return (root.findtext("Status"), root.findtext("ErrorCode"),
            root.findtext("ErrorMessage") or root.findtext("ReferenceCode"))

def bericht_anfordern():
    r = requests.get(f"{BASE}/SendRequest", headers=HEADERS, timeout=30,
                     params={"t": TOKEN, "q": QUERY_ID, "v": 3})
    r.raise_for_status()
    st = statusantwort(r.text)
    if not st or st[0] != "Success":
        raise RuntimeError(f"SendRequest fehlgeschlagen: {st}")
    return st[2]                                 # ReferenceCode

def bericht_abholen(ref, versuche=8, pause=10):
    for i in range(versuche):
        time.sleep(pause * (i + 1))              # wachsende Wartezeit
        r = requests.get(f"{BASE}/GetStatement", headers=HEADERS, timeout=120,
                         params={"t": TOKEN, "q": ref, "v": 3})
        r.raise_for_status()
        st = statusantwort(r.text)
        if st is None:
            return r.text                        # fertiger Bericht (XML oder CSV)
        if st[1] not in NOCHMAL:
            raise RuntimeError(f"GetStatement: {st[1]} {st[2]}")
    raise TimeoutError("Bericht nicht rechtzeitig fertig")

if __name__ == "__main__":
    inhalt = bericht_abholen(bericht_anfordern())
    with open("flex_bericht.xml", "w", encoding="utf-8") as f:
        f.write(inhalt)

Wer bereits mit ib_async arbeitet, findet dort eine Klasse FlexReport, die Abruf und Auswertung in einem Schritt erledigt. Laut Quellcode (Stand Oktober 2026) nutzt sie für den zweiten Schritt allerdings die von IBKR als veraltet bezeichnete URL aus der Antwort und fragt im Sekundentakt nach. Prüfen Sie daher vor dem Einsatz, ob dieser Ablauf zur aktuellen IBKR-Doku passt; der eigene, kurze Client oben ist leichter zu überwachen und anzupassen. Den fertigen Bericht parsen Sie anschließend etwa mit xml.etree.

Welche Fehlercodes und Limits gelten?

IBKR führt eine zentrale Liste der Fehlercodes, die SendRequest und GetStatement zurückgeben können. Für den Betrieb reicht es, sie in zwei Gruppen zu teilen: Codes, bei denen ein späterer Versuch sinnvoll ist, und Codes, die einen Eingriff von Ihnen verlangen. Die wichtigsten im Überblick:

Code 1025 hat IBKR laut Changelog am 16.10.2026 in die Liste aufgenommen. Die Doku beschreibt nicht, ob danach Abrufe gesperrt werden und für wie lange. Gerade deshalb sollte Ihr Programm bei Konfigurationsfehlern wie 1014, 1015 oder 1013 nicht endlos weiterprobieren, sondern nach wenigen Versuchen abbrechen und eine Meldung schicken. Eine Schleife, die bei jedem Fehler sofort neu sendet, verstößt außerdem schnell gegen das Limit von 10 Anfragen pro Minute.

Typisch ist ein Abruf der Activity-Daten am frühen Morgen und, falls nötig, wenige Abrufe des Trade-Confirmation-Berichts über den Tag.

Flex-Bericht mit den Daten des Trading-Bots abgleichen.

Ein Trading-Bot führt eigene Aufzeichnungen: welche Orders er geschickt hat, welche Ausführungen er gemeldet bekam und welche Position er glaubt zu halten. Diese Sicht kann vom tatsächlichen Kontostand abweichen, etwa nach Verbindungsabbrüchen, Teilausführungen, manuellen Eingriffen oder Korrekturen durch den Broker. Der Flex-Bericht ist hier die unabhängige Gegenprobe. Er ergänzt den laufenden Positionsabgleich im Bot, der beim Start und im Betrieb direkt über die API prüft, ersetzt ihn aber nicht.

Für einen belastbaren Abgleich braucht es eindeutige Schlüssel. Die TWS API vergibt für jede Teilausführung eine eigene execId; eine Korrektur erkennen Sie laut IBKR daran, dass sich die ID nur in den Ziffern nach dem letzten Punkt unterscheidet. Zusätzlich können Sie jeder Order eine eigene Kennung im Feld orderRef mitgeben, die über die gesamte Lebensdauer der Order erhalten bleibt. Im Flex-Bericht taucht sie als Order Reference auf, sofern die Audit-Trail-Felder aktiv sind. Ein typischer Ablauf am Morgen nach dem Handelstag:

1. Activity-Bericht des Vortags abrufen und unverändert archivieren
2. Ausführungen anhand von Ausführungs-ID oder Order Reference den Bot-Einträgen zuordnen
3. Stückzahl, Preis, Gebühren und Zeitpunkt je Paar vergleichen, mit kleiner Toleranz für Rundungen
4. Ausführungen ohne Gegenstück auf beiden Seiten auflisten
5. Endpositionen je Instrument aus dem Bericht mit dem Bot-Zustand vergleichen
6. Bei Abweichungen Alarm auslösen und den Bot erst nach Klärung wieder handeln lassen

Wichtig ist die Richtung der Korrektur. Der Abgleich sollte Abweichungen melden, aber nicht automatisch den Bot-Zustand überschreiben oder gar Ausgleichsorders senden. Eine Differenz kann viele Ursachen haben, und die falsche automatische Reaktion vergrößert den Schaden. Die abgeglichenen Daten eignen sich anschließend auch als Grundlage für ein Trading-Journal mit Python, weil sie die tatsächlichen Ausführungen statt der vom Bot erwarteten enthalten.

Im Paper-Konto lässt sich der Abgleich über die Order Reference nicht testen, weil die Audit-Trail-Felder dort derzeit fehlen. Testen Sie die Zuordnung dort über Ausführungs-IDs, Symbol, Zeit und Stückzahl und schalten Sie die Order Reference erst im Live-Konto zu.

Token sicher ablegen und rotieren.

Der Token ist faktisch ein Lesezugang zu Ihren Kontodaten: Positionen, Ausführungen, Cash-Bewegungen und je nach gewählten Feldern auch Angaben zum Kontoinhaber. Handeln lässt sich damit nicht, aber wer ihn hat, kann Ihre Berichte abrufen. Behandeln Sie ihn deshalb wie ein Passwort.

• Nicht im Code: Token und Query-ID gehören in Umgebungsvariablen, eine Secret-Verwaltung des Servers oder eine Datei mit eingeschränkten Leserechten, nie in ein Git-Repository.
• Nicht in Logs: Der Token steht als Parameter in der URL. Protokollieren Sie daher keine vollständigen Anfrage-URLs und maskieren Sie den Wert in Fehlermeldungen.
• IP-Sperre nutzen: Läuft der Abruf auf einem Server mit fester IP, beschränken Sie den Token auf diese Adresse. Ein abgegriffener Token ist dann von anderswo wertlos.
• Laufzeit bewusst wählen: Ein Jahr ist bequem, eine kürzere Laufzeit begrenzt den Schaden bei einem Leck. Tragen Sie das Ablaufdatum in einen Kalender ein und lassen Sie Ihr Programm bei Fehler 1012 sofort melden.
• Rotation üben: Neuen Token erzeugen, im Secret-Speicher ersetzen, Testabruf starten, Ergebnis prüfen.

Auch die abgerufenen Berichte verdienen Schutz. Legen Sie sie verschlüsselt oder zumindest mit eingeschränkten Rechten ab und löschen Sie Zwischenkopien.

Grenzen und Risiken des Flex Web Service.

Der Flex Web Service ist ein Reporting-Werkzeug, kein Ersatz für die Handelsschnittstelle. Daraus ergeben sich klare Grenzen:

• Verzögerung: Ausführungen erscheinen mit einigen Minuten Abstand, Activity-Daten nur einmal täglich. Für Risikokontrolle, Stopps oder Positionsprüfung während des Handels taugt das nicht; dafür braucht der Bot die Live-Daten der TWS API oder Web API.
• Kein Polling: Die Limits von 1 Anfrage pro Sekunde und 10 pro Minute sowie Code 1025 bestrafen aggressive Abrufschleifen.
• Verknüpfte Konten: Der Token ist nur im Master-Konto sichtbar, und Queries hängen an Benutzername und Kontenauswahl. Wer Strukturen umbaut, muss Vorlagen oft neu anlegen.
• Paper-Konto: Audit-Trail-Felder wie Order Reference fehlen dort derzeit, Tests bilden den Live-Betrieb also nicht vollständig ab.
• Datenstand: Korrekturen, Stornos und nachträglich gebuchte Gebühren können Werte nach dem ersten Abruf noch ändern. Der Abgleich sollte das berücksichtigen, statt den ersten Stand als endgültig zu behandeln.
• Doku im Wandel: IBKR hat die Dokumentation 2026 umgebaut, ältere Seiten sind verschoben oder verschwunden. Endpunkte, Codes und Limits vor einem Update gegen die aktuelle Fassung prüfen.

Auch inhaltlich bleibt der Dienst ein Datenlieferant. Er sagt nichts darüber, ob eine Strategie funktioniert, und er nimmt keine steuerliche Bewertung vor. Wer die Daten für Steuer oder Buchhaltung nutzt, sollte Auswertungen mit der Steuerberatung abstimmen. Und wie bei jedem automatisierten Handel gilt: Fehler in Bot oder Abgleich können zu Verlusten führen, bei gehebelten Produkten auch über den Einsatz hinaus.

Was Sie jetzt konkret tun können.

Mit diesen Schritten haben Sie in kurzer Zeit einen funktionierenden, überwachten Abruf:

1. Im Client Portal eine schlanke Activity Flex Query im Format XML mit festem Zeitraum (Last Business Day) anlegen und die Query-ID notieren.
2. Den Flex Web Service aktivieren und einen Token mit passender Laufzeit und, wenn möglich, IP-Beschränkung erzeugen.
3. Token und Query-ID als Umgebungsvariablen auf dem Server hinterlegen und das Beispiel oben einmal von Hand ausführen.
4. Fehlercodes in „erneut versuchen“ und „Eingriff nötig“ aufteilen und für die zweite Gruppe eine Benachrichtigung einrichten.
5. Den Abruf als zeitgesteuerten Job am frühen Morgen einplanen und die Rohberichte archivieren.
6. Im Bot jede Order mit einer eindeutigen Order Reference versehen und im Live-Konto die Audit-Trail-Felder aktivieren.
7. Einen Abgleich bauen, der Abweichungen meldet, aber nichts automatisch korrigiert, und das Ablaufdatum des Tokens in den Kalender eintragen.

Wenn Sie den Abruf in ein bestehendes Handelssystem einbinden wollen, lohnt sich ein Blick auf die gesamte Datenkette: Bot-Protokoll, Live-API, Flex-Bericht und Journal sollten dieselben Schlüssel verwenden.

Häufige Fragen.

Brauche ich für die IBKR Flex Query API eine laufende TWS?

Nein. Der Flex Web Service arbeitet unabhängig von TWS und IB Gateway. Sie brauchen nur einen im Client Portal erzeugten Token und die Query-ID einer zuvor angelegten Flex Query. Die eigentlichen Zugangsdaten werden beim Abruf nicht verwendet, nur für die Verwaltung von Token und Vorlagen im Client Portal.

Wie lange ist ein Flex Web Service Token gültig?

Laut IBKR-Doku können Sie beim Erzeugen eines neuen Tokens eine Gültigkeit zwischen 6 Stunden und 1 Jahr wählen und den Zugriff auf bestimmte IP-Adressen beschränken. Ist der Token abgelaufen, antwortet der Dienst mit Fehlercode 1012. Dann erzeugen Sie im Client Portal einen neuen Token und hinterlegen ihn in Ihrem Programm.

Was bedeutet der Flex-Fehlercode 1019?

Code 1019 heißt, dass der Bericht noch erstellt wird. Das ist kein echter Fehler, sondern ein Hinweis, etwas zu warten. Ihr Programm sollte GetStatement nach einer Pause erneut aufrufen, am besten mit wachsenden Abständen. Zu dichte Anfragen mit demselben Token beantwortet der Dienst mit Fehler 1018; dokumentiert ist ein Limit von 1 Anfrage pro Sekunde und 10 pro Minute.

Liefert der Flex Web Service Trades in Echtzeit?

Nein. Laut IBKR-Doku (Fassung Juni 2026) stehen neue Ausführungen in Trade-Confirmation-Berichten typischerweise erst nach 5 bis 10 Minuten zur Verfügung, Activity-Daten werden nur einmal täglich zum Geschäftsschluss aktualisiert. Für Entscheidungen während des Handels braucht ein Bot die Live-Daten der TWS API oder der Web API. Flex eignet sich für Journal, Archiv und den Abgleich am Tagesende.

Warum fehlt die Order Reference in meinem Flex-Bericht?

Die Order Reference gehört zu den Audit-Trail-Feldern. Sie erscheint nur, wenn diese Felder in der Flex Query aktiviert sind. Laut IBKR stehen sie außerdem derzeit nur im Live-Konto zur Verfügung, nicht im Paper-Konto. Für Tests im Paper-Konto ordnen Sie Ausführungen deshalb über Ausführungs-ID, Symbol, Zeit und Stückzahl zu.

Quellen und Stand.

• Flex Web Service: Enable and Create Access Token — Interactive Brokers
• Web API Reference: SendRequest (Parameter, Limits, Antwortformat) — Interactive Brokers
• Flex Web Service: Error Codes — Interactive Brokers
• Flex Web Service: Including Audit Trail Fields — Interactive Brokers
• Web API Changelog vom 16.10.2026 (Fehlercode 1025) — Interactive Brokers
• Web API Reference: GetStatement (Bericht und Fehlerantwort) — Interactive Brokers
• Flex Web Service, Fassung vom 17.06.2026 mit Hinweisen zu Aktualität und Polling (archiviert) — Interactive Brokers via Internet Archive
• TWS API Reference: Execution (execId, orderRef) — 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 Ausführungen und Kontoauszüge aus IBKR automatisch mit Ihrem Trading-Bot abgleichen? Unverbindlich anfragen — wir klären Datenquellen, Abgleichregeln und den Betrieb auf Ihrem Server. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.