Tradovate-API-Bracket-Orders (OSO/OCO) schlagen fehl

Ihre Automatisierung sendet eine Tradovate-API-Bracket-Order, die Eröffnung wird auf ES oder NQ ausgeführt, und dann… nichts. Kein Stop-Loss, kein Take-Profit. Sie sind jetzt einen schlechten Tick von einer ungesicherten Position entfernt, und Ihr Log meldet, die Order sei “erfolgreich gesendet” worden. Das ist die Falle. 2026 ist der klassische Fehler kein rotes Fehlerbild mehr, sondern ein 200 OK HTTP-Status, der einen failureReason und failureText im Body verbirgt, oder ein orderStrategy-Aufruf, der als nackter 404 zurückkommt. Die häufigsten Varianten: ein 404 (undocumented) von startOrderStrategy, ein Invalid JSON-Parsing-Fehler, eine Wrong OCO combination-Ablehnung, und die tückischste, eine stille Teilausführung, bei der nur die Eröffnung übrig bleibt. Hier erfahren Sie, was jeder Fehler wirklich bedeutet, wie Sie die dahinterliegenden Endpoint- und Feldprobleme beheben, und wie PickMyTrade verhindert, dass eine ungesicherte Ausführung jemals in Ihrem Konto ankommt.

Was „Wrong OCO Combination“ und die 404-Fehler bedeuten

Tradovate bietet Ihnen mehrere Möglichkeiten, geschützte Orders einzureichen, und jede scheitert auf ihre eigene Art. Ein Bracket ist eine Eröffnungsorder plus zwei Kind-Legs, ein schützender Stop und ein Gewinnziel, wobei die Ausführung oder Stornierung eines Kindes das andere storniert. Auf der REST-API bauen Sie das mit order/placeOSO (One-Sends-Other): Eine übergeordnete Order trägt bracket1- und bracket2-Objekte, die erst aktiv werden, nachdem die übergeordnete Order ausgeführt wurde. order/placeOCO (One-Cancels-Other) verknüpft zwei Orders so, dass eine Ausführung bei einer die andere storniert, praktisch, um einen Stop und ein Ziel an eine bereits gehaltene Position anzuhängen.

Das Verwirrende daran: Diese Endpoints liefern anstandslos 200 OK, während sie die Order trotzdem ablehnen. Tradovate meldet Business-Logic-Fehler im Response-Body, nicht im HTTP-Status. Ein Payload, der sauber beim Server ankommt, kann also trotzdem mit {"failureReason": "InvalidPrice", "failureText": "Wrong OCO combination"} zurückkommen, was bedeutet, dass die gewählten Preisniveaus oder die Order-Typ-Kombination keine gültige OCO ergeben. Ein Stop und ein Limit auf der falschen Marktseite reichen dafür aus. Behandeln Sie jeden Body mit failureReason als Ablehnung, ganz gleich, was die Statuszeile sagt.

Der Endpoint orderStrategy/startOrderStrategy ist ein anderes Kaliber. Er führt eine serverseitige Bracket-Strategie aus, das API-Äquivalent einer ATM-Strategie, und ist bei seinem Payload deutlich wählerischer. Senden Sie die falsche orderStrategyTypeId, oder rufen Sie ihn über einfaches REST auf, obwohl er einen WebSocket-Frame erwartet, erhalten Sie einen wenig hilfreichen 404 (undocumented). Das sieht nach einer fehlenden Route aus, ist aber tatsächlich eine abgelehnte Anfrage.

Häufigste Ursachen für fehlschlagende Tradovate-API-Bracket-Orders

1. Sie haben nur den HTTP-Status geprüft, nicht den Body

Das ist die Falle Nummer eins. Ihr Client sieht 200 OK, protokolliert „Order gesendet“ und macht weiter, dabei wurde die Eröffnung abgelehnt, oder nur die übergeordnete Order kam durch. Parsen Sie jede OSO/OCO-Antwort auf failureReason und failureText, bevor Sie das Bracket als live einstufen.

2. Falsche orderStrategyTypeId bei startOrderStrategy

Viele probieren orderStrategyTypeId: 1 und ernten dafür einen 404 (undocumented). Es gibt nur einen gültigen Wert, und das ist 2. Alles andere wird abgelehnt, bevor die Strategie überhaupt aufgebaut wird.

3. Aufruf von startOrderStrategy über REST statt WebSocket

Selbst mit der richtigen Type-ID ist dieser Endpoint über einfaches HTTP-REST unzuverlässig. Er ist dafür gebaut, über einen WebSocket zu laufen, und funktioniert zuverlässig, wenn Sie ihn so ansteuern. Ein REST-Aufruf, der ständig mit 404 fehlschlägt, gelingt oft unverändert, sobald Sie ihn als WebSocket-Frame senden.

4. Fehlerhaftes JSON oder ein rohes Dictionary statt eines JSON-Bodys

Ein häufiger placeOCO-Fehler ist Invalid JSON: expected '{', offset: 0x00000075. Das passiert, wenn die Anfrage ein formkodiertes Dictionary statt eines serialisierten JSON-Strings verschickt, in Python etwa, wenn Sie data=payload statt json=payload übergeben (oder json.dumps() vergessen). Der Server sieht nie gültiges JSON und verwirft das gesamte Bracket.

5. Fehlendes accountSpec, falsche accountId oder eine unzulässige Preiskombination

Bracket-Endpoints verlangen sowohl die numerische accountId (aus account/list) als auch den String accountSpec (Ihr Kontoname). Fehlt eines von beiden, erhalten Sie Access is denied. Unabhängig davon prüfen placeOCO und placeOSO, ob die beiden Legs eine gültige Kombination bilden, ein Stop und ein Limit, die auf der falschen Marktseite bepreist sind, kommen als Wrong OCO combination zurück. Market-Entry-Brackets bringen noch eine weitere Komplikation mit: Weil die API konkrete Preisniveaus für die Kind-Legs benötigt, können Sie in der Regel kein Tick-relatives TP/SL an eine reine Market-Eröffnung über placeOSO anhängen. Sie berechnen die Preisniveaus entweder selbst, oder überlassen die Offsets der Strategy-Engine.

So beheben Sie Tradovate-API-Bracket-Orders: Schritt für Schritt

Die Falle „200 OK, aber keine Legs“ beheben

• Parsen Sie nach jedem Aufruf von placeOSO / placeOCO / startOrderStrategy den JSON-Body.
• Prüfen Sie auf einen failureReason-Schlüssel. Ist er vorhanden, behandeln Sie die Order als abgelehnt und lesen Sie failureText für die Ursache.
• Markieren Sie das Bracket erst dann als live, wenn Sie bestätigte Order-IDs für die übergeordnete Order und beide Kind-Legs haben, pollen Sie dafür order/list oder abonnieren Sie Order-Events über WebSocket.
• Protokollieren Sie den vollständigen Body, nicht nur den Statuscode, damit Teilausführungen in Ihrem Audit-Trail sichtbar werden.

startOrderStrategy-404-Fehler beheben

• Setzen Sie orderStrategyTypeId auf 2, den einzigen akzeptierten Wert.
• Senden Sie sowohl accountId als auch accountSpec, dazu symbol, action und das params-Objekt (mit Ihrer entryVersion und brackets).
• Senden Sie die Anfrage als WebSocket-Frame statt als REST-POST. Dieser Endpoint ist dafür ausgelegt, über den WebSocket zu laufen, und das erwartete Frame-Format ist gut dokumentiert.
• Wiederholen Sie denselben Payload über den Socket, bevor Sie annehmen, Ihr JSON sei fehlerhaft, der 404 liegt meist am Transport, nicht am Schema.

Invalid JSON und Wrong OCO combination beheben

• Serialisieren Sie den Payload als JSON. Verwenden Sie in Python requests requests.post(url, headers=..., json=payload), niemals data=payload mit einem Dictionary.
• Stellen Sie sicher, dass der Header Content-Type: application/json gesetzt ist.
• Prüfen Sie bei placeOCO die Geometrie der beiden Legs: Stop und Limit müssen für die Richtung der Position auf entgegengesetzten, gültigen Seiten des aktuellen Preises liegen. Sehen Sie Wrong OCO combination, tauschen Sie das Leg auf der falschen Seite aus.
• Warten Sie bei einer Market-Eröffnung entweder auf die Ausführung und hängen Sie ein placeOCO-Stop/Target an die entstandene Position, oder wechseln Sie zu startOrderStrategy, das relative Offsets akzeptiert.

Der zuverlässige Fallback: getrennte Eröffnung + OCO

Wenn ein natives Bracket einfach nicht mitspielen will, entkoppeln Sie die Eröffnung von den Exits. Platzieren Sie die Eröffnungsorder eigenständig mit order/placeOrder, bestätigen Sie die Ausführung, und senden Sie dann ein placeOCO, das den schützenden Stop mit dem Gewinnziel gegen die nun offene Position koppelt. Das ist ein zusätzlicher Roundtrip, umgeht aber den Strategy-Endpoint vollständig und gibt Ihnen explizite Kontrolle über jedes Leg.

Fehlerbehebungstabelle

So verhindert PickMyTrade das

Wenn Sie OSO/OCO-Payloads selbst bauen, tragen Sie die Verantwortung für jeden der oben genannten Fehlermodi. PickMyTrade sitzt zwischen Ihren TradingView-Alerts und Tradovate und übernimmt die Bracket-Verkabelung für Sie:

• Bracket- & OCO-Handling, hängt Stop-Loss- und Take-Profit-Legs korrekt an, sodass eine Eröffnung nie ungeschützt bleibt.
• Response-Validierung, prüft die vollständige Order-Antwort, nicht nur den HTTP-Status, und deckt echte Ablehnungen auf statt eines falschen „Erfolgs“.
• Entitlement- & Risikofilter, berücksichtigt den Datenvereinbarungsstatus Ihres Kontos und Prop-Firm-Limits, bevor eine Order weitergeleitet wird.
• Rate-Limit-sicheres Routing, staffelt den Order-Flow, damit Bracket-Legs nicht an Request-Obergrenzen abprallen.
• Multi-Account-Sync, spiegelt dasselbe geschützte Bracket über alle verbundenen Konten hinweg.