IBKR-API-Order nicht übertragen: Precautions und Rückfragen.

Bleibt eine Order, die Ihr Programm über die API an Interactive Brokers schickt, in der Trader Workstation (TWS) als „nicht übertragen“ mit einem Transmit-Knopf stehen, liegt es in der Regel an einer von drei Ursachen: einem Fehler in der Order, einer greifenden Vorsichtsregel (Order Precaution) oder dem Order-Feld transmit mit dem Wert False. In der Client Portal Web API zeigt sich dasselbe Prinzip anders: Statt einer Order-ID kommt eine Rückfrage, die Ihr Code bestätigen muss. Dieser Artikel erklärt Stand Oktober 2026 die von IBKR dokumentierten Bestätigungsmechanismen: die Precautions und Bypass-Optionen in TWS und IB Gateway, die Precautionary Settings in den Presets, die Warnung bei Orders ohne IBKR-Marktdaten, Order-Reply-Messages und ihre Unterdrückung, Server-Prompts sowie die automatische Wiedervorlage nach Verbindungsabbrüchen. Dazu kommt, wie ein Bot den Status PendingSubmit sauber behandelt und warum pauschales Abschalten aller Warnungen ein echtes Risiko ist.

Warum bleiben API-Orders bei IBKR hängen?

Die Ursache steckt selten im Netzwerk. Es gibt drei typische Gründe, warum eine API-Order in TWS als nicht übertragen erscheint: Die Order enthält einen Fehler, eine Vorsichtsregel von TWS verhindert die Übertragung, oder das Feld transmit im Order-Objekt steht auf False. Der Standardwert ist True. Wer ihn bei Bracket-Orders bewusst auf False setzt, muss die letzte Order der Gruppe mit True senden, sonst bleibt die ganze Gruppe liegen.

Nicht übertragene Orders existieren laut IBKR nur in der laufenden TWS-Sitzung, verschwinden beim Neustart und lassen sich über die API übertragen oder stornieren, aber nicht abfragen. Ein zweiter häufiger Befund ist der Status PendingSubmit. IBKR definiert ihn so: Die Order wurde übertragen, aber es liegt noch keine Bestätigung vor, dass das Ziel sie angenommen hat. Die ältere TWS-API-Doku nennt als häufigsten Grund eine geschlossene Börse. In der Web API kann PendingSubmit zusätzlich auf eine offene Rückfrage hindeuten, die Ihr Code beantworten muss.

Die folgende Übersicht ordnet die Symptome den Ursachen zu:

Die Codes stammen aus der Fehlerliste der TWS API. Bei der Sammelmeldung 399 nennt erst der Text den eigentlichen Grund.

Order Precautions in TWS: welche es gibt und wann sie greifen.

TWS prüft jede Order gegen eine Reihe von Vorsichtsregeln, bevor sie das Haus verlässt. Im Standard bedeutet das laut IBKR: Kundinnen und Kunden müssen eine Warnung bestätigen und die Order manuell übertragen. Für Orders aus der API gibt es eigene Schalter unter Global Configuration, API, Precautions. Die Doku listet unter anderem:

• „Bypass Order Precautions for API orders“ als allgemeiner Schalter für die Precautions,
• eigene Bypass-Optionen für Anleihen-Warnungen, negative Rendite auf Endfälligkeit (Yield to Worst) und gekündigte Anleihen,
• die Warnung bei Paar-Trades mit gleicher Richtung („same action pair trade“),
• die preisbasierte Volatilitätswarnung,
• die Warnung zu US-Aktien-Marktdaten in Stückzahlen,
• die Warnung bei direkt gerouteten Aktienorders (Redirect),
• die Vorsichtsregel „No Overfill Protection“ für bestimmte Handelsziele.

Getrennt davon stehen die eigentlichen Grenzwerte. Sie liegen in Global Configuration, Presets, je Instrumententyp, im Block Precautionary Settings. Dort legen Sie etwa fest, wie weit ein Limitpreis vom aktuellen Kurs abweichen darf, wie groß eine Order höchstens sein darf und welchen Gesamtwert sie nicht überschreiten soll. IBKR schreibt, man könne diese Werte strenger oder lockerer setzen oder mit 0 ganz deaktivieren, und rät ausdrücklich, jede Einstellung vorher sorgfältig zu lesen. Ein dritter Ort ist der Bereich Messages: Dort lassen sich einzelne Warnmeldungen abschalten, zum Beispiel die Cross-Side-Warnung (Code 2137), die erscheint, wenn eine Order eine Position von long nach short dreht.

Für die Praxis wichtig: Wer einen Bot auf einen Server umzieht oder ein Paper-Konto neu einrichtet, sollte nicht davon ausgehen, dass die bisherigen Einstellungen dort schon gelten, sondern sie neu prüfen. Die aktuelle TWS-API-Doku beschreibt zusätzlich Protobuf-Aufrufe (reqConfigProtoBuf, updateConfigProtoBuf), mit denen ein Programm API-Einstellungen einschließlich der Precautions abfragen und ändern kann. Laut IBKR geht das ab TWS API 10.44, und der Read-Only-Zugriff muss vorher manuell abgeschaltet sein.

Bypass oder nicht? Schutzfunktion gegen Komfort abwägen.

Die Vorsichtsregeln sind im Kern ein „fat finger“-Schutz, also Schutz gegen Tippfehler und Fehleingaben. Genau dieser Gedanke gilt auch für einen Bot. Ein Preis in Cent statt Dollar oder eine verrutschte Dezimalstelle bei der Stückzahl sind die maschinellen Gegenstücke zum Tippfehler. Die Prozent-, Größen- und Wertgrenzen der Presets sind dann die letzte Kontrolle vor der Börse.

Ein vollautomatischer Bot kann aber nicht auf einen Menschen warten, der in TWS auf Transmit klickt. Deshalb ist die Frage nicht „Bypass ja oder nein“, sondern welche Prüfung an welcher Stelle sitzt. Drei Varianten kommen infrage:

1. Grenzen anpassen statt abschalten. Die Precautionary Settings so setzen, dass normale Orders Ihrer Strategie durchgehen, grobe Ausreißer aber weiter hängen bleiben. Das erfordert, die eigene Ordergröße und die übliche Preisabweichung zu kennen.
2. Bypass mit eigener Prüfschicht. Die API-Precautions abschalten und dieselben Grenzen im Bot nachbauen: maximale Stückzahl, maximaler Orderwert, maximale Abweichung vom letzten Kurs, Plausibilität der Instrumente. Das verlagert die Verantwortung vollständig in Ihren Code.
3. Getrennte Benutzer. IBKR erlaubt mehrere Benutzernamen für ein Konto. Ein eigener API-Benutzer mit eigenen Presets kann die Einstellungen des Bots von denen des manuellen Handels trennen; ob das in Ihrem Setup greift, prüfen Sie im Paper-Konto. Marktdaten-Abos werden allerdings für jeden Live-Benutzernamen getrennt eingerichtet.

In allen drei Fällen lohnt eine Prüfschicht im Bot, die unabhängig von den Broker-Einstellungen greift. Wie ein übergeordneter Notaus aussieht, der bei Auffälligkeiten alle Orders stoppt, beschreibt der Artikel zum Kill-Switch für Trading-Bots.

Warum Orders ohne IBKR-Marktdaten hängen bleiben.

Viele Bots beziehen ihre Kurse nicht von Interactive Brokers, sondern von einem anderen Datenanbieter, und nutzen IBKR nur für die Ausführung. Für diesen Fall dokumentiert IBKR eine eigene Standardwarnung: „You are trying to submit an order without having market data for this instrument“. Die so geprüfte Order wird nicht automatisch übertragen, solange niemand in TWS auf Transmit klickt. In der Web API heißt die entsprechende Rückfrage o354 und warnt, dass Orders ohne Marktdaten zu fehlerhaften und unerwarteten Trades führen können.

Tückisch: Ein Bot, der lange sauber läuft, bleibt nach einer Abo-Änderung, bei einem neuen Instrument oder im neuen Paper-Konto plötzlich hängen. IBKR weist darauf hin, dass Marktdaten an den Benutzernamen gebunden sind: Ein Paper-Konto bekommt Echtzeitdaten in der Regel nur, wenn der Live-Benutzer seine Abos per Market Data Sharing mit ihm teilt. Ohne Daten kann TWS zudem die Prozentgrenze nicht prüfen, das meldet Fehlercode 164.

Zwei saubere Wege führen aus der Lage. Entweder abonnieren Sie für die gehandelten Instrumente die passenden IBKR-Marktdaten, dann kann TWS die Precautions wie vorgesehen prüfen. Oder Sie entscheiden sich bewusst für den Bypass und übernehmen die Preisprüfung vollständig im Bot, mit den Kursen Ihres externen Anbieters als Referenz. Am riskantesten ist der Zustand dazwischen: weder Daten noch eigene Prüfung.

Web API: Order-Reply-Messages und Server-Prompts.

In der Client Portal Web API wartet keine Order in einem Fenster. Stattdessen antwortet der Server auf POST /iserver/account/{accountId}/orders mit einer Order-Reply-Message: einem Objekt mit id, dem Meldungstext, isSuppressed und einer Liste messageIds. IBKR betont, dass das keine Ablehnung ist; im Beispiel der Doku überschreitet der Preis eine Prozentgrenze von 3 %. Die Order geht erst an den Markt, wenn Ihr Code die Meldung mit POST /iserver/reply/{id} und dem Inhalt {"confirmed": true} bestätigt. Im Erfolgsfall kommt dann die eigentliche Bestätigung mit order_id und Status. Es können weitere Rückfragen folgen, die ebenfalls beantwortet werden müssen. Laut IBKR-Referenz muss die Antwort sofort erfolgen; andere Anfragen dazwischen können die Order verwerfen. Schlägt die Bestätigung fehl, gleicht der Bot zuerst ab, statt neu zu senden.

Die messageIds ordnen die Meldung einer Kategorie zu. IBKR listet die unterdrückbaren Kategorien, darunter:

Mit POST /iserver/questions/suppress und einer Liste von messageIds unterdrücken Sie diese Kategorien für den Rest der laufenden Brokerage-Sitzung des Benutzers. IBKR empfiehlt, die Liste zu Beginn der Sitzung vor dem ersten Trade zu senden. Wer während der Sitzung eine weitere Kategorie ergänzt, schickt die komplette Liste erneut. POST /iserver/questions/suppress/reset hebt alle Unterdrückungen wieder auf. Weil die Unterdrückung an die Sitzung gebunden ist, gehört sie in die Startroutine nach jeder neuen Anmeldung.

Zusätzlich beschreibt IBKR sogenannte Server-Prompts. Sie betreffen Rückfragen mit mehr als einer Ja-Nein-Antwort, im Beispiel von IBKR die Frage, ob der Price Management Algo verwendet werden soll. Der Ablauf in groben Zügen:

1. Ein Websocket muss bereits vor dem Absenden der Order laufen, denn die Rückfrage kommt als unaufgeforderte Nachricht über diesen Kanal. Für den laufenden Orderstatus bietet sich zusätzlich das Live-Order-Thema sor an.
2. Die Order-Antwort per REST zeigt noch keinen endgültigen Status, typischerweise PendingSubmit.
3. Auf dem Websocket kommt unter dem Thema ntf eine Nachricht mit Order-ID, einer Anfrage-ID (reqId), dem Text und den möglichen Antworten.
4. Ihr Code sendet POST /iserver/notification mit Order-ID, reqId und genau einer der angebotenen Antworten. Den weiteren Orderstatus verfolgt der Bot danach wie gewohnt über den Websocket.

Wer Web-API-Orders nur per REST ohne Websocket verschickt, kann solche Fragen nicht beantworten, weil die nötige reqId laut IBKR nur über den Websocket kommt.

Status PendingSubmit im Bot behandeln (Python-Skizze).

Ein Bot sollte jede Order als Zustandsmaschine führen: gesendet, bestätigt, aktiv, teilweise oder ganz ausgeführt, storniert oder abgelehnt. Über die TWS API meldet orderStatus jede Änderung; IBKR weist darauf hin, dass dabei häufig doppelte Meldungen kommen. Warnungen und Ablehnungen laufen getrennt über den error-Callback, bei Orders in der Regel mit der Order-ID als reqId. Eine von einer Precaution blockierte Order kann laut IBKR auch als Inactive erscheinen. Entscheidend ist eine Zeitgrenze: Bleibt eine Order länger als erwartet in PendingSubmit oder ganz ohne Status, darf der Bot sie nicht einfach erneut senden, weil die erste Order später doch noch übertragen werden könnte. Er gleicht stattdessen mit den offenen Orders ab und meldet den Fall. Findet der Abgleich die Order nicht, kann sie in TWS als nicht übertragen hängen, denn solche Orders liefert die API nicht zurück.

# Skizze mit der offiziellen ibapi, nur im Paper-Konto testen
import time
from ibapi.client import EClient
from ibapi.wrapper import EWrapper

HAENGT_NACH = 15                     # Sekunden ohne Bestätigung
KLAEREN = ("PendingSubmit", "Inactive")  # Inactive: u. a. Fehler, Reject, Precaution
WARNCODES = (109, 163, 164, 399)     # Precaution- und Order-Meldungen

class Bot(EWrapper, EClient):
    def __init__(self):
        EClient.__init__(self, self)
        self.orders = {}             # orderId -> Zustand

    def sende(self, oid, contract, order):
        self.orders[oid] = {"status": "gesendet", "seit": time.time()}
        self.placeOrder(oid, contract, order)

    def orderStatus(self, orderId, status, filled, remaining, avgFillPrice,
                    permId, parentId, lastFillPrice, clientId, whyHeld,
                    mktCapPrice):
        o = self.orders.setdefault(orderId, {"seit": time.time()})
        if o.get("status") != status:          # Duplikate ignorieren
            o.update(status=status, seit=time.time(), why=whyHeld)

    # Signatur ab TWS API 10.33; ältere haben kein errorTime
    def error(self, reqId, errorTime, errorCode, errorString,
              advancedOrderRejectJson=""):
        if reqId in self.orders and errorCode in WARNCODES:
            self.orders[reqId]["warnung"] = (errorCode, errorString)

    def pruefe_haengende(self, melde):
        jetzt = time.time()
        auffaellig = [oid for oid, o in self.orders.items()
                      if o.get("status") in KLAEREN + ("gesendet",)
                      and jetzt - o["seit"] > HAENGT_NACH]
        if auffaellig:
            self.reqOpenOrders()               # Abgleich statt Neuversand
        for oid in auffaellig:
            o = self.orders[oid]
            melde(f"Order {oid}: {o.get('status')} {o.get('warnung')}")

Die Skizze zeigt nur die Logik; im echten System kommen Netzwerk-Thread, Locks, openOrder-Auswertung und ein persistentes Protokoll dazu. Wie sich Orders mit unklarem Status gegen das Konto abgleichen lassen, beschreibt der Artikel zum Positionsabgleich für Trading-Bots.

Eine nützliche Vorab-Prüfung ist whatIf. Setzen Sie im Order-Objekt whatIf = True, durchläuft die Order laut IBKR die Margin-Prüfung, ohne ausgeführt zu werden. Das Ergebnis kommt im OrderState des openOrder-Callbacks: Margin vorher, nachher und die Veränderung, die erwartete Kommission samt Gebühren und gegebenenfalls ein warningText. Die Precautions der Presets ersetzt das nicht.

Ein letzter Mechanismus betrifft Verbindungsabbrüche. Die Einstellung „Maintain and resubmit orders when connection is restored“ unter Global Configuration, API, Settings ist laut IBKR standardmäßig aktiv. Orders, die während eines Verbindungsverlusts eingehen, speichert TWS und sendet sie nach, sobald die Verbindung zurück ist; das gilt laut IBKR auch für den automatischen Neustart. Wird TWS in dieser Zeit geschlossen, gehen sie unabhängig von der Einstellung verloren. Für einen Bot, der auf aktuelle Kurse reagiert, kann eine nachgereichte Order veraltet sein. Ob das gewünscht ist, sollten Sie bewusst entscheiden und im Code berücksichtigen.

Risiken pauschal abgeschalteter Warnungen.

Der bequemste Weg, hängende Orders loszuwerden, ist zugleich der gefährlichste: alle Bypass-Haken setzen, alle Presets auf 0, in der Web API die komplette Beispiel-Liste aus der Doku unterdrücken. Danach geht jede formal gültige Order ohne Rückfrage an den Markt. Die konkreten Risiken:

• Fehlorders in voller Größe. Ein Fehler in der Stückzahl- oder Preisberechnung wird nicht mehr abgefangen. Bei gehebelten Produkten wie Futures oder Optionen kann das Verluste weit über den geplanten Einsatz hinaus verursachen.
• Stille Annahmen. Wer o354 unterdrückt, handelt womöglich ohne verlässliche Kursreferenz, ohne es zu merken.
• Vergessene Einstellungen. Auf 0 gesetzte Presets aus einer Testphase gelten ohne getrennte Benutzer auch für den manuellen Handel weiter.
• Automatisch nachgereichte Orders. In Kombination mit der Wiedervorlage nach Verbindungsabbruch können veraltete Orders ohne jede Rückfrage ausgeführt werden.

Precautions verhindern bestimmte Bedienfehler, nicht Verluste aus der Strategie selbst. Automatisierter Handel kann bis zum Totalverlust des eingesetzten Kapitals führen, bei Hebelprodukten auch darüber hinaus. Für den ersten Live-Betrieb eines Bots bieten sich kleine Größen und eng gesetzte Grenzen an, die erst mit Erfahrung gelockert werden.

Was Sie jetzt konkret tun können.

Wenn Ihre API-Orders heute hängen oder Sie einen neuen Bot vorbereiten, hilft diese Reihenfolge:

1. Im error-Callback alle Codes und Texte mitschreiben, insbesondere 109, 163, 164, 399 und 2137, und bei hängenden Orders zuerst diese Meldungen lesen.
2. Im Order-Objekt prüfen, ob transmit irgendwo auf False steht, vor allem bei Bracket- und Gruppen-Orders.
3. In TWS oder IB Gateway die Bereiche API, Precautions, Presets und Messages durchgehen und die aktuellen Werte dokumentieren, für Live- und Paper-Benutzer getrennt.
4. Klären, ob für jedes gehandelte Instrument IBKR-Marktdaten für die API vorliegen; falls nicht, bewusst zwischen Abo und Bypass mit eigener Preisprüfung entscheiden.
5. In der Web API die Antwortlogik für Reply-Messages bauen, die Unterdrückungsliste bewusst klein halten und in die Startroutine jeder Sitzung legen, außerdem vor der ersten Order den Websocket mit ntf und sor starten.
6. Im Bot eine Zeitgrenze für PendingSubmit einführen, mit Abgleich statt Neuversand und einer Meldung an Sie.
7. Die Einstellung zur Wiedervorlage nach Verbindungsabbruch bewusst setzen und mit einem gezielt getrennten Netzwerk im Paper-Konto testen.

Wenn Sie die Orderstrecke Ihres Systems lieber prüfen oder neu aufbauen lassen wollen, finden Sie unter Trading-Automatisierung die Leistungsbeschreibung. Ich entwickle und teste das System, die Live-Aktivierung auf Ihrem Konto nehmen Sie selbst vor.

Häufige Fragen.

Warum wird meine Interactive-Brokers-API-Order nicht übertragen?

Meist gibt es drei Gründe: Die Order enthält einen Fehler, eine Vorsichtsregel von TWS oder IB Gateway greift, oder das Feld transmit im Order-Objekt steht auf False. Häufig betroffen sind Orders ohne IBKR-Marktdaten für das Instrument und Orders, deren Preis oder Größe die Grenzen in den Presets überschreitet. Die Meldungen im error-Callback, etwa die Codes 109, 163 oder 164, nennen in der Regel den konkreten Grund.

Wo finde ich Bypass Order Precautions for API orders?

In TWS und IB Gateway unter Global Configuration, dann API und Precautions. Dort stehen neben dem allgemeinen Schalter weitere Bypass-Optionen, etwa für Anleihen, Volatilitätswarnungen oder direkt geroutete Aktienorders. Die eigentlichen Grenzwerte für Preisabweichung, Größe und Orderwert liegen getrennt davon in den Presets unter Precautionary Settings. Prüfen Sie die Einstellungen für jeden Benutzernamen und jede Installation getrennt.

Was bedeutet PendingSubmit bei IBKR?

PendingSubmit heißt laut IBKR, dass die Order übertragen wurde, aber noch keine Bestätigung des Ziels vorliegt. Als häufigsten Grund für einen länger anhaltenden Status nennt IBKR eine geschlossene Börse. In der Web API kann zusätzlich ein offener Server-Prompt dahinterstecken, den der Code über den Websocket beantworten muss. Ein Bot sollte dann abgleichen und melden, nicht die Order erneut senden.

Wie bestätige ich eine Order-Reply-Message in der IBKR Web API?

Die Antwort auf die Order enthält eine id. Diese senden Sie per POST an /iserver/reply/{id} mit dem Inhalt confirmed gleich true. Danach kommt im Erfolgsfall die Order-Bestätigung mit order_id, es können aber auch weitere Rückfragen folgen. Wiederkehrende Kategorien lassen sich über /iserver/questions/suppress für die laufende Sitzung unterdrücken. IBKR empfiehlt, das zu Beginn der Sitzung vor dem ersten Trade zu tun.

Sollte ich alle Order-Warnungen für meinen Trading-Bot abschalten?

Pauschal abschalten ist riskant, weil die Warnungen als Schutz gegen Fehleingaben gedacht sind. Besser ist, die Grenzwerte in den Presets an die eigene Strategie anzupassen oder bei einem Bypass dieselben Preis-, Größen- und Wertgrenzen im Bot selbst zu prüfen. Getrennte Benutzernamen für Bot und manuellen Handel können verhindern, dass Test-Einstellungen unbemerkt den Handel von Hand betreffen.

Quellen und Stand.

• General Third Party Frequently Asked Questions (untransmitted orders, warning without market data) — Interactive Brokers
• Understanding Order Precautions (Messages, Presets, Precautionary Settings) — Interactive Brokers, TWS API Documentation
• Intelligent Order Resubmission — Interactive Brokers, TWS API Documentation
• Order Submission (Transmit, PendingSubmit, Inactive, WhatIf) — Interactive Brokers, TWS API Legacy Documentation
• Message Codes (109, 163, 164, 399, 2137) — Interactive Brokers, TWS API Legacy Documentation
• Place Order Reply Confirmation (/iserver/reply) — Interactive Brokers, Web API Documentation
• Order Reply Suppression (/iserver/questions/suppress) — Interactive Brokers, Web API Documentation
• Order Server Prompt (ntf, /iserver/notification) — Interactive Brokers, Web API Documentation

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

Ihre API-Orders hängen oder Ihr Bot soll mit sauberer Orderstrecke starten? Unverbindlich anfragen — wir klären Precautions, Prüfschicht im Code, Fehlerbehandlung und Tests im Paper-Konto. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.