Tradovate API liquidatePosition-Endpunkt liefert 404

Sie möchten eine Position per Code glattstellen und senden dazu einen POST an den Liquidate-Endpunkt, in Erwartung einer sauberen Schließung. Stattdessen liefert der Server 404 Not Found zurück. Ihr Token ist gültig, Ihre anderen Order-Aufrufe funktionieren, das JSON sieht einwandfrei aus, und trotzdem verhält sich genau diese Route so, als würde sie nicht existieren. Frustrierend, weil es sich anfühlt, als wäre der Endpunkt defekt oder fehle.

Ist er nicht. Ein 404 ist enger gefasst, als es sich anfühlt: Es geht nicht um Ihr Konto, Ihre Position oder Ihren Payload. Es bedeutet, dass die exakte URL, an die Sie gePOSTet haben, keiner Route auf Tradovates Server entspricht. In neun von zehn Fällen liegt es an einer von drei Sachen: Der Pfad ist falsch geschrieben oder in falscher Groß-/Kleinschreibung, Sie zeigen auf den falschen Host, oder Sie haben das falsche HTTP-Verb gesendet. Prüfen wir das der Reihe nach aus, um dann den korrekten Aufruf festzulegen, damit Sie sauber glattstellen können.

Was ein 404 Ihnen wirklich sagt

Jeder HTTP-Fehler zeigt auf eine andere Ebene, und wenn man sie durcheinanderbringt, bearbeitet man das Falsche. Ein 404 bedeutet, dass der Pfad nicht existiert. Ein 401 bedeutet, dass der Pfad existiert, Sie aber nicht autorisiert waren. Ein 400 bedeutet, dass Pfad und Autorisierung in Ordnung waren, Ihr Body aber fehlerhaft war. Ein 429 bedeutet, dass Sie das Rate-Limit erreichen. Wenn Sie also vor einem echten 404 stehen, hören Sie auf, an Ihrem JSON-Body herumzudoktern, der Server ist gar nicht so weit gekommen, dass er sich dafür interessiert hätte. Er konnte die Route nicht einmal finden.

Allein diese Tatsache grenzt die Suche stark ein. Alles, was einen 404 verursacht, liegt in der Request-Zeile: die Methode, der Host, das Versionssegment und die Schreibweise des Pfads. Gehen Sie diese vier durch, und der Fehler verschwindet.

Ursache 1: Der Pfad ist falsch geschrieben oder in falscher Groß-/Kleinschreibung

Das ist der große Klassiker, der fast jeden mindestens einmal erwischt. Die REST-Pfade von Tradovate unterscheiden zwischen Groß- und Kleinschreibung. Die Operation wird exakt liquidatePosition geschrieben, kleines l, camelCase mit großem P. Schreiben Sie es anders, hat der Router nichts zum Abgleichen und antwortet mit 404. Alles in Kleinbuchstaben zu schreiben ist der klassische Fehler, meist weil man es aus dem Gedächtnis getippt hat oder das Framework die URL automatisch normalisiert hat.

Die Lösung ist unspektakulär, aber zuverlässig: Kopieren Sie den Operationsnamen direkt aus der API-Referenz und fügen Sie ihn ein, statt ihn neu einzutippen. Ein einziges falsches Zeichen in der Groß-/Kleinschreibung reicht bereits aus. Prüfen Sie dabei gleich auf einen versehentlichen abschließenden Schrägstrich oder ein doppeltes Segment wie /order/order/liquidatePosition, das sich ein URL-Builder einschleichen kann.

Ursache 2: Falscher Host oder fehlendes Versionssegment

Die vollständige URL besteht aus vier Teilen, die alle stimmen müssen: Schema, Host, das /v1-Versionssegment und der Pfad. Setzt man sie zusammen, erhält man:

• Demo/Simulation: https://demo.tradovateapi.com/v1/order/liquidatePosition
• Live: https://live.tradovateapi.com/v1/order/liquidatePosition

Lassen Sie das /v1 weg, bekommen Sie einen 404, denn direkt an der Wurzel der API hängt keine Route /order/liquidatePosition. Ein Tippfehler im Host bewirkt dasselbe oder lässt die DNS-Auflösung komplett scheitern. Und greifen Sie hier nicht zum Marktdaten-Host: md.tradovateapi.com bedient Kurse, DOM und Charts, nicht Order-Operationen, sodass ein md-Host auch keinen Liquidate-Aufruf routen wird.

Eine Feinheit ist erwähnenswert: Das Mischen von Umgebungen, ein Demo-Token gegen den Live-Host oder umgekehrt, zeigt sich häufiger als 401 denn als 404, ist aber trotzdem einen Blick wert, sobald Ihr Pfad sauber ist. Hostnamen werden gelegentlich aktualisiert, prüfen Sie die aktuellen daher in Tradovates eigener Entwicklerdokumentation, statt einer URL zu vertrauen, die Sie aus einem alten Gist kopiert haben.

Ursache 3: Sie haben die falsche HTTP-Methode gesendet

Die Liquidate-Operation ist nur per POST erreichbar. Senden Sie ein GET, hat der Server für diesen Pfad keinen GET-Handler, was sich je nach Client als Not-Found- oder Method-Not-Allowed-artiger Fehler zeigt. Das passiert leicht, wenn Sie testen, indem Sie die URL in die Adressleiste des Browsers einfügen, das ist immer ein GET und schlägt hier daher immer fehl.

Testen Sie mit einem echten POST aus einem geeigneten Client. Sie brauchen außerdem die richtigen Header in der Anfrage: Content-Type: application/json und Authorization: Bearer <yourAccessToken>. Ein POST, bei dem der Body an der falschen Stelle sitzt, oder ohne JSON-Content-Type, kann auf Arten fehlschlagen, die wie ein Routing-Problem aussehen, selbst wenn der Pfad stimmt.

Ursache 4: Singular oder Plural, welcher ist der echte?

Hier entsteht ein Großteil der Verwirrung nach dem Motto “der Endpunkt fehlt”. Die kanonische Operation pro Position ist die Singular-Route /order/liquidatePosition. Sie nimmt eine accountId und eine einzelne contractId entgegen und stellt genau diese eine Nettoposition glatt. Das ist die Route, die Sie dokumentiert finden, und diejenige, die zuverlässig antwortet.

Manche Client-Bibliotheken und Community-Snippets verweisen auf eine Plural-Variante im Batch-Stil, die statt eines einzelnen Contracts ein positions-Array entgegennimmt. Kopieren Sie ein Plural-Beispiel, obwohl Ihr Ziel nur die Singular-Route bereitstellt, oder gehen Sie davon aus, dass der Singular ein Array akzeptiert, erhalten Sie entweder einen 404 oder senden einen Body, den der Endpunkt ignoriert. Im Zweifel greifen Sie zum Singular /order/liquidatePosition mit accountId und contractId und prüfen den exakten Operationsnamen sowie die Form anhand der aktuellen API-Referenz für die Version, die Sie aufrufen. Die Schreibweise und die Wahl zwischen Singular und Plural sind genau die zwei Details, die still und leise einen 404 verursachen.

Der korrekte Aufruf, Feld für Feld

Sobald die Request-Zeile stimmt, ist der Body kurz.

POST https://demo.tradovateapi.com/v1/order/liquidatePosition
{ "accountId": 12345, "contractId": 67890, "admin": false, "customTag50": "" }

Bei den beiden IDs bleiben die meisten hängen, gehen Sie also gezielt vor. Rufen Sie /account/list auf und lesen Sie die id aus dem Kontoobjekt aus, mit dem Sie handeln möchten. Rufen Sie /position/list auf, und jede offene Position liefert Ihnen sowohl eine accountId als auch eine contractId zusammen mit ihrer Nettomenge. Kopieren Sie genau diese Zahlen, der Endpunkt arbeitet mit dem Paar (accountId, contractId), nicht mit einer Positions-ID oder einem Symbol-String.

Die Admin-Falle: Ein 401, der sich hinter Ihrer Lösung versteckt

Diese Falle schnappt genau in dem Moment zu, in dem der 404 behoben ist. Das Feld admin ist im Body erforderlich, aber der Wert, den Sie ihm geben, ist entscheidend. Setzen Sie admin: true, obwohl Ihr API-Benutzer nicht für Admin-Zugriff bereitgestellt ist, kippt der Aufruf direkt zu 401 Unauthorized. Setzen Sie admin: false, geht dieselbe Anfrage durch. Solange Sie also nicht wissen, dass Ihr Benutzer Admin-Rechte besitzt, senden Sie "admin": false. Wenn Sie gerade einen 404 behoben haben und jetzt direkt beim nächsten Versuch auf einen 401 starren, ist das fast immer der Grund, nicht Ihr Token, nicht Ihre Konto-ID.

Was der Endpunkt Ihnen gibt, und was nicht

Ein paar Verhaltensweisen sollten Sie kennen, bevor Sie auf diesem Aufruf aufbauen:

• Er stellt die gesamte Nettoposition glatt für dieses Paar (accountId, contractId). Im Hintergrund platziert er eine schließende Order, was bedeutet, dass sie nicht ausgeführt wird, wenn der Markt geschlossen ist, führen Sie ihn während der Handelszeiten des Instruments aus.
• Es ist ein Aufruf pro Contract. Um alles auf einem Konto glattzustellen, rufen Sie /position/list ab und iterieren, wobei Sie pro offener contractId einen liquidatePosition-Aufruf auslösen. Es gibt auf dieser Route keinen einzelnen “gesamtes Konto glattstellen”-Body.
• Er ist race-sicher. Wurde die Position zwischen Ihrer Prüfung und dem Aufruf bereits geschlossen, etwa weil ein Stop ausgeführt wurde, erhalten Sie einen sauberen 200 mit leerem Body statt eines Fehlers. Das ist Absicht und sicherer, als eine Order auf der Gegenseite zu konstruieren, die versehentlich eine gegenläufige Position eröffnen könnte.
• Er liefert keine orderId zurück. Da in der Antwort keine Order-ID enthalten ist, können Sie den Schlusskurs der Ausführung nicht direkt auslesen. Benötigen Sie diesen Preis für die P&L-Berechnung, gleichen Sie ihn mit den Ausführungs- und Fill-Berichten (Execution Reports, Fill-Paare) oder dem Positionslog ab.

Eine schnelle Checkliste, um den 404 zu beheben

Wo PickMyTrade ins Spiel kommt

Die meisten, die mit diesem 404 kämpfen, wollen eigentlich gar nicht zu Tradovate-API-Klempnern werden, sie wollen eine Strategie, die Positionen eröffnet, verwaltet und schließt, ohne dass man Endpunkte, IDs und Tokens ständig im Auge behalten muss. PickMyTrade leitet TradingView-Alerts an Tradovate weiter und kann Positionen im Rahmen einer Strategie schließen oder glattstellen, sodass Sie Liquidate-Aufrufe nicht von Hand bauen, Konto- und Contract-IDs nicht hinterherjagen und Tokens nicht selbst verwalten müssen.

• Keine handgebauten Liquidate-Aufrufe Ihre Strategie eröffnet und stellt auf Tradovate glatt, ohne eine einzige handgeschriebene API-Anfrage.
• Konto- und Contract-Auflösung übernommen die IDs, an denen rohe Aufrufe scheitern, werden für Sie aufgelöst.
• Verwaltete Authentifizierung Tokens und Hosts werden automatisch gehandhabt, sodass ein 401, der sich hinter einem 404 versteckt, nie zu Ihrem Problem wird.
• Rate-Limit-sicheres Routing staffelt den Orderfluss, sodass nichts an Tradovates Anfragelimits abprallt.