Tradovate API: 'Access is denied' bei der Orderplatzierung

Sie verbinden einen Bot mit der Tradovate-REST-API, die erste Live-Order geht raus, und zurück kommt Access is denied. Das fühlt sich wie eine Mauer an. Ihre Zugangsdaten haben funktioniert. Die Authentifizierung hat Ihnen ein Token gegeben. Sie können sogar Ihre Positionen sehen. Trotzdem lehnt /order/placeOrder jede Order mit derselben knappen Meldung ab, mal als 401, mal als HTTP 200 mit {"failureReason":"UnknownReason","failureText":"Access is denied"} im Body. Die gute Nachricht: Das ist fast nie ein Problem mit einem “defekten Schlüssel”. Es ist einer von vier banalen, leicht behebbaren Fehlern: die falsche Account-ID, eine zu knapp bemessene Orders-Berechtigung, der falsche Demo-/Live-Host oder ein falsch gesetztes isAutomated-Flag. Im Folgenden finden Sie die vollständige Checkliste, was der Fehler wirklich bedeutet, jede Ursache mit einer schrittweisen Lösung und wie PickMyTrade diese ganze Fehlerklasse umgeht, damit Ihre TradingView-Alerts ohne JSON-Debugging bei Marktöffnung an Tradovate weitergeleitet werden.

Was "Access is denied" bedeutet

Access is denied ist Tradovates generische Antwort im Sinne von “diese Anfrage ist dazu nicht berechtigt”. Die Falle dabei: Es ist kein Authentifizierungsfehler im üblichen Sinne, Sie können ein völlig gültiges, nicht abgelaufenes Access Token besitzen und die Meldung trotzdem bekommen. Sie tritt genau dann auf, wenn Tradovate prüft, ob dieses Token berechtigt ist, diese Order auf diesem Account zu platzieren. Jeder Bruch in dieser Kette, eine Account-ID, die dem Token nicht gehört, ein API-Key, dem nie das Recht zur Orderplatzierung erteilt wurde, oder ein Token, das gegen den Demo-Host ausgestellt und dann gegen Live verwendet wird, erscheint als dieselben drei Wörter.

Hier sind zwei Antwortformen relevant. Ein rohes 401 Access Denied deutet meist auf das Token oder den Host hin: Das Token ist abgelaufen, wurde von der falschen Base-URL angefordert, oder (im Live-Modus) das Gerät ist nicht freigegeben. Ein 200 OK, dessen Body {"failureReason":"UnknownReason","failureText":"Access is denied"} enthält, bedeutet, dass die Anfrage authentifiziert wurde, die Order selbst aber auf Berechtigungsebene abgelehnt wurde, klassischerweise wegen einer falschen accountId oder einer fehlenden Orders-Berechtigung.

Da beide Varianten dieselbe Meldung ausgeben, verbringt man leicht eine Stunde damit, Passwörter zu überprüfen, obwohl der eigentliche Fehler in einem einzigen Feld des Request-Bodys liegt. Prüfen Sie zuerst den HTTP-Status und arbeiten Sie dann die unten genannten Ursachen der Reihe nach durch.

Top-Ursachen für "Access is denied" beim Place Order

1. Sie senden den Anzeigenamen statt der numerischen Account-ID

Das ist die mit Abstand häufigste Ursache. Ihr Account zeigt einen Namen wie DEMO1235 oder TRAD123456 an, und es ist verlockend, die abschließende Zahl als accountId zu übergeben. Aber accountId ist Tradovates interne Entity-ID, ein separater numerischer Wert, der nichts mit den Ziffern im Anzeigenamen zu tun hat. Übergeben Sie die falsche ID, gehört der Account dem Token nicht “offiziell”, und die Order wird abgelehnt.

Die Lösung besteht darin, beide Kennungen aus /account/list auszulesen. Jedes Account-Objekt liefert eine id (die numerische Entity-ID, die Sie in accountId eintragen) und einen name (die lesbare Bezeichnung, die Sie in accountSpec eintragen). Kurz gesagt: Die Account-ID ist nicht die Zahl, nach der Ihr Account zufällig benannt ist. Codieren Sie sie niemals fest, sondern rufen Sie sie immer ab.

2. Die Orders-Berechtigung des API-Keys ist nicht Full Access

Bei Tradovate lässt sich ein API-Key pro Fähigkeit einschränken. Ein Key kann Positionen lesen, Account-Informationen lesen und die Kontraktbibliothek lesen, während Orders trotzdem auf weniger als Full Access gesetzt ist, was genau ausreicht, um sich zu authentifizieren, Accounts aufzulisten und gesund zu wirken, aber sofort blockiert wird, sobald eine Order platziert werden soll. Die Lösung ist direkt: Gewähren Sie dem Key in Ihren Tradovate-Anwendungs-/API-Einstellungen Orders → Full Access und stellen Sie das Token danach neu aus, damit die neue Berechtigung wirksam wird.

3. Sie haben das Token auf einem Host erstellt und bestellen auf einem anderen

Tradovate betreibt zwei vollständig getrennte Umgebungen mit zwei Base-URLs:

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

Ein Token, das vom Demo-Host angefordert wurde, ist nur gegenüber dem Demo-Host gültig. Richten Sie dieses Token auf das Live-/order/placeOrder (oder umgekehrt), erhalten Sie Access is denied. Der klassische Fehler besteht darin, auth/accessTokenRequest mit einer fehlerhaften oder nicht passenden Base-URL aufzurufen und sich dann zu fragen, warum jede folgende Order fehlschlägt. Stellen Sie sicher, dass Ihr Auth-Aufruf und Ihr Order-Aufruf denselben Host-String verwenden, Zeichen für Zeichen, und dass der Host zu dem Account passt, mit dem Sie tatsächlich handeln möchten.

4. isAutomated fehlt oder hat den falschen Typ

Löst ein Bot, ein Algorithmus oder ein anderer unpersönlicher Prozess die Order aus, verlangen die CME-Regeln isAutomated: true; ein Mensch, der auf einen UI-Button klickt, ist false. Neben dem bloßen Angeben des Flags müssen Sie auf den Datentyp achten. Wenn Sie JSON per POST senden, ist isAutomated ein Boolean (true). Wenn Sie den Body aber form-encodieren (data= statt json= in Pythons requests), wird alles in Strings serialisiert, sodass der Wert als String "true" übertragen werden muss. Ein Boolean, der stillschweigend auf False fällt, oder ein Typ, den der Server nicht parsen kann, führt Sie direkt zurück zu Access is denied.

5. Symbolformat und (bei Live) ein nicht freigegebenes Gerät

Zwei seltenere Ursachen runden die Liste ab. Erstens das Symbolformat: Ein abgelaufener oder fehlerhafter Kontrakt, ein alter Verfallscode oder ein fortlaufendes/Rollover-Symbol, das die API nicht routen kann, kann als Ablehnung erscheinen statt als eindeutiger “ungültiges Symbol”-Fehler. Der Wechsel zum aktiven Frontmonat-Kontrakt (oder dessen Kontrakt-ID) behebt das. Zweitens die Geräte-ID im Live-Modus: Live wird strikt durchgesetzt, dass Orders von einer bekannten, freigegebenen deviceId kommen, die bei auth/accessTokenRequest übergeben wurde, während Demo dies weitgehend ignoriert. Wenn Ihr Code im Demo-Modus Orders platziert, aber nur im Live-Modus abgelehnt wird, ist das der Hinweis.

So beheben Sie "Access is denied": Schritt für Schritt

Troubleshooting-Tabelle

Wo PickMyTrade ansetzt

Die meisten “Access is denied”-Tickets entstehen dadurch, dass die Auth- und Order-Logik selbst gebaut wird. PickMyTrade entfernt diese gesamte Fehlerfläche, indem es die Tradovate-Verbindung für Sie vermittelt:

• Verwaltete Authentifizierung & Host-Routing, der richtige Demo-/Live-Host und ein aktuelles, gültiges Token werden automatisch verwaltet, sodass eine abgelaufene Session nie als Berechtigungsfehler erscheint.
• Account- & Berechtigungsauflösung, die richtige numerische Account-ID und die Orders-Berechtigung werden aus Ihrem verknüpften Account ermittelt, nicht aus einem Anzeigenamen geraten.
• Regelkonforme isAutomated-Behandlung, automatisierte Orders werden jedes Mal korrekt gemäß den Börsenregeln gekennzeichnet, ohne Boolean-vs.-String-Fallstricke.
• Symbol- & Kontraktvalidierung, Alerts werden einem gültigen, aktiven Kontrakt zugeordnet, bevor überhaupt eine Order gesendet wird, was die Fehlerklasse “Ablehnung wegen ungültigem Symbol” eliminiert.