Tradovate API 401 Unauthorized (abgelaufenes Token)

Sie richten einen Tradovate-API-Bot ein, senden ein paar Demo-Orders ab, und alles läuft rund, doch nach etwa anderthalb Stunden läuft plötzlich jeder Aufruf in einen 401 Unauthorized. Das ist einer der häufigsten und am meisten missverstandenen Tradovate-API-Fehler, und die Ursache ist fast immer dieselbe: Ihr Zugriffstoken ist still und leise abgelaufen. Tradovate-Zugriffstoken gelten für etwa 90 Minuten. Sobald diese Zeit abgelaufen ist, vertrauen Ihnen weder die REST-API noch der Marktdaten-WebSocket mehr. Sie sehen dies als reinen 401 Unauthorized-HTTP-Status, als Meldung "Access is denied", oder als WebSocket, der abrupt einen Close-Frame sendet und die Verbindung trennt. Die Lösung besteht nicht darin, den Login-Endpunkt erneut zu bombardieren, sondern das Token vor Ablauf zu erneuern. Automatisierungs-Bridges wie PickMyTrade übernehmen diesen Token-Lebenszyklus für Sie, sodass Ihre Alerts weiter auslösen, selbst wenn ein einfaches Skript längst ausgefallen wäre.

Was „401 Unauthorized“ bedeutet

Ein 401 Unauthorized der Tradovate-API bedeutet, dass der Server Ihre Anfrage erhalten, aber die Ausführung verweigert hat, weil er kein gültiges, aktuelles Zugriffstoken verifizieren konnte. Es handelt sich um einen Authentifizierungsfehler, nicht um ein Berechtigungsproblem und nicht um ein Problem der Order-Logik. Die API sagt im Grunde: “Ich weiß gerade nicht, wer Sie sind.” Auf der REST-Seite sehen Sie dies als HTTP-401-Status. Beim Marktdaten- und Trading-WebSocket kommt meist ein Frame mit "s":401 und dem Text "Access is denied" an, oft gefolgt vom Schließen der Verbindung.

Das Verwirrende daran: Ein Tradovate-Zugriffstoken ist absichtlich kurzlebig. Wenn Sie sich über /auth/accessTokenRequest authentifizieren, erhalten Sie in der Antwort ein accessToken sowie eine expirationTime, die etwa 90 Minuten in der Zukunft liegt. Während dieses Zeitfensters ist das Token Ihr Schlüssel zu jedem geschützten Endpunkt. Sobald es abläuft, liefert exakt dieselbe Anfrage, die eine Minute zuvor noch funktioniert hat, einen 401-Fehler, weil der Schlüssel das Schloss nicht mehr öffnet.

Deshalb ist der Fehler beim ersten Auftreten so verwirrend. An Ihrem Code hat sich nichts geändert, Ihr API-Key und Ihr Secret sind weiterhin korrekt, und dennoch schlagen die Aufrufe fehl. Das Problem ist die Zeit, nicht die Konfiguration. Ein 401-Fehler, der erst auftritt, nachdem Ihre App über eine Stunde gelaufen ist, ist das typische Erkennungsmerkmal eines abgelaufenen Tokens.

Die häufigsten Ursachen für Tradovate API 401 Unauthorized im Jahr 2026

1. Das Zugriffstoken ist abgelaufen (das 90-Minuten-Limit)

Das ist mit Abstand die häufigste Ursache. Tradovate-Zugriffstoken haben laut Dokumentation eine Lebensdauer von etwa 90 Minuten ab Erstellung. Holt sich Ihr Bot beim Start einmalig ein Token und aktualisiert es nie wieder, liefert jede Anfrage nach dieser 90-Minuten-Marke einen 401-Fehler. In der Praxis tritt der Fehler meist um die 80-Minuten-Marke auf, genau dort, wo ein nie erneuertes Token versagt.

2. Zu späte Erneuerung, nachdem das Token bereits abgelaufen ist

/auth/renewAccessToken funktioniert nur, solange Ihr aktuelles Token noch gültig ist. Warten Sie bis nach Ablauf, um zu erneuern, schlägt bereits der Erneuerungsaufruf selbst mit einem 401 fehl, Sie versuchen dann, eine Erneuerung mit einem toten Schlüssel zu authentifizieren. Ist ein Token vollständig abgelaufen, müssen Sie einen neuen /auth/accessTokenRequest ausführen, keine Erneuerung.

3. Ein fehlerhaft formatierter Authorization-Header

Selbst ein völlig gültiges Token wird abgelehnt, wenn Sie es falsch übermitteln. Bei REST-Aufrufen muss der Header Authorization: Bearer <token> lauten, ein fehlendes Bearer-Präfix oder ein überflüssiges Leerzeichen genügt, um einen 401-Fehler auszulösen. Beim WebSocket muss der authorize-Frame exakt gemäß der aktuellen Dokumentation formatiert sein (Endpunkt, ID, dann das Token, mit den korrekten Leerzeilen-Trennungen). Ein Formatierungsfehler führt dort zur gleichen "Access is denied"-Antwort.

4. Falsche Umgebung (Demo-Token auf Live-Host oder umgekehrt)

Tradovate betreibt getrennte Demo- und Live-Umgebungen. Ein für den Demo-Host ausgestelltes Token autorisiert keine Anfragen an den Live-Host, und umgekehrt gilt dasselbe. Richten Sie ein gültiges Demo-Token gegen einen Live-Endpunkt (oder ein Live-Token gegen Demo), erscheint ein 401 / Zugriff verweigert, obwohl das Token selbst echt ist.

5. Das Token wurde durch einen zweiten Login ungültig gemacht

Zugriffstoken sind an eine Sitzung gebunden. Fordert ein anderer Prozess, ein zweites Skript, ein manueller Test oder ein erneuter Durchlauf Ihres eigenen Login-Ablaufs ein neues Token für dasselbe Konto an, kann dies das Token ungültig machen, das Ihr Bot noch verwendet. Der Bot sammelt dann mitten im Lauf 401-Fehler, obwohl sich auf seiner Seite “nichts geändert hat”. Und wiederholtes Bombardieren des Login-Endpunkts kann Tradovates Anfrage-Sperre auslösen, was Sie zusätzlich verzögert.

So beheben Sie den 401-Unauthorized-Fehler: Schritt für Schritt

Ein abgelaufenes Token beheben: Vor Ablauf erneuern

Ein bereits abgelaufenes Token beheben

Ist Ihr Token bereits abgelaufen und liefert die Erneuerung einen 401-Fehler, versuchen Sie nicht weiter zu erneuern. Führen Sie erneut einen vollständigen /auth/accessTokenRequest aus, um ein brandneues Token und eine neue Ablaufzeit zu erhalten, und setzen Sie dann die oben beschriebene Erneuerungs-Schleife fort. Bauen Sie Ihren Client so, dass ein 401 bei jedem Aufruf genau eine erneute Authentifizierung und einen automatischen Wiederholungsversuch auslöst, keine Endlosschleife, die Anfrage-Sperren auslösen kann.

Den Authorization-Header beheben

Protokollieren Sie den genauen Header, den Ihr Client sendet, und prüfen Sie, ob er Authorization: Bearer <token> mit genau einem Leerzeichen nach Bearer lautet. Prüfen Sie bei WebSocket-Verbindungen, ob der authorize-Frame dem aktuell dokumentierten Format entspricht, bevor Sie annehmen, Ihr Token sei fehlerhaft. Am schnellsten grenzen Sie das Problem ein, indem Sie denselben Aufruf mit einem frisch ausgestellten Token in einem REST-Client, Postman oder curl, durchführen. Gelingt dies, liegt das Problem daran, wie Ihr Code die Anfrage erstellt, nicht am Token.

Umgebungs- und Zugangsdaten-Konflikte beheben

Prüfen Sie, ob der Host, den Sie aufrufen, zu der Umgebung passt, für die Ihr Token ausgestellt wurde (Demo vs. Live). Überprüfen Sie anschließend, ob Ihr API-Key, Secret und Ihre App-Zugangsdaten im Tradovate-API-Verwaltungsbereich aktuell sind, ein Neu-Generieren oder ein Synchronisationsverlust führt ebenfalls zu Authentifizierungsfehlern. Melden Sie sich in Ihrem Tradovate-Konto an, öffnen Sie den Bereich API-Zugriff / Add-on und bestätigen Sie, dass Ihr Key aktiv ist, bevor Sie das Token verantwortlich machen.

Fehlerbehebungstabelle

So verhindern Sie das mit PickMyTrade

Eine 90-Minuten-Token-Uhr manuell zu verwalten ist fehleranfällig, verpassen Sie eine Erneuerung, verstummt Ihre Automatisierung genau dann, wenn ein Signal auslöst. PickMyTrade sitzt zwischen TradingView und Tradovate und übernimmt den Token-Lebenszyklus für Sie:

• Automatische Token-Erneuerung, die Verbindung wird planmäßig aktualisiert, sodass ein 90-Minuten-Ablauf nie Ihre Orders verwirft.
• Sitzungssicheres Routing, eine verwaltete Verbindung pro Konto vermeidet die durch doppelte Logins verursachte Ungültigmachung, die 401-Fehler mitten im Lauf auslöst.
• Ratenlimit-sichere Anfragen, Aufrufe werden zeitlich gestaffelt, um Tradovates Anfragelimits einzuhalten, sodass Sie einen behobenen 401-Fehler nie gegen eine Sperrfrist eintauschen.
• Umgebungsbewusstsein, Demo und Live bleiben strikt getrennt, sodass ein Token nie an den falschen Host gesendet wird.

Das Ergebnis: Ihre TradingView-Alerts erreichen Tradovate, ohne dass Sie auch nur eine einzige Zeile Authentifizierungscode schreiben oder überwachen müssen.