Tradovate user/syncrequest WS 401 Access Denied beheben

Sie haben einen WebSocket geöffnet, user/syncrequest abgefeuert, und anstelle eines Streams aus Konto- und Orderdaten erhielten Sie glatt ein 401 mit “Access is denied.” An Ihrem Login ist nichts falsch, und am Konto ist nichts kaputt. Der Socket wurde schlicht nie autorisiert, sodass der Server jede Anfrage darauf als anonym behandelt. Die Lösung ist eine bestimmte Reihenfolge der Operationen: Holen Sie sich ein Access-Token vom REST-Auth-Endpunkt, übergeben Sie es dem Socket in einem authorize-Frame, warten Sie auf die Erfolgsantwort, und erst dann senden Sie user/syncrequest. Bekommen Sie diese Reihenfolge richtig hin, verschwindet der 401.

Das hier bringt fast jeden zu Fall, der den Tradovate-Socket zum ersten Mal von Hand verdrahtet, meist weil er versucht, so zu authentifizieren, wie REST funktioniert. WebSockets funktionieren hier nicht so. Gehen wir genau durch, was passiert, und den sauberen Ausweg.

So sieht der Fehler tatsächlich aus

In Ihrem Frame-Log sehen Sie den Verbindungsaufbau des Sockets, das Eintreffen des Open-Frames, dann kommt Ihr user/syncrequest direkt mit einer Ablehnung zurück. Es sieht in etwa so aus:

<-- o
--> user/syncrequest
1

<-- a[{"i":1,"s":401,"d":"Access is denied"}]

Der Verräter ist der Status 401 gepaart mit Access is denied auf dem Anfrage-Frame. Wenn Sie zuvor nie eine Status-200-Antwort auf einen authorize-Frame gesehen haben, ist das Ihre Antwort: Der Socket ist nicht authentifiziert.

Warum der Socket einen 401 wirft

Es gibt eigentlich nur eine Handvoll Grundursachen, und sie stapeln sich in vorhersehbarer Reihenfolge.

1. Der Socket wurde nie autorisiert

Das ist der große Fall. Eine rohe WebSocket-Verbindung zu Tradovate ist unauthentifiziert. Sie zu öffnen und sofort user/syncrequest zu senden, ist, als würde man in einen Mitgliederclub gehen und ein Getränk bestellen, ohne den Ausweis zu zeigen. Sie müssen genau einen authorize-Frame pro Verbindung senden, der ein gültiges Access-Token trägt, bevor irgendetwas anderes durchgeht.

2. Sie haben versucht, das Token über den Socket zu holen

Ein häufiger Fehltritt ist der Versuch, accessTokenRequest über den WebSocket selbst aufzurufen. Dieser Endpunkt liegt auf der REST-Seite. Das Token wird über HTTPS geprägt und dann dem Socket vorgelegt. Der Socket stellt niemals Token aus.

3. Ein environment-Parameter in der Token-Anfrage

Wenn Sie einen Anfrage-Body irgendwoher kopiert haben und er "environment": "demo" (oder "live") enthält, entfernen Sie es. Dieses Feld wird von accessTokenRequest nicht akzeptiert und kann die gesamte Anfrage aus der Bahn werfen. Die Umgebung wird durch den Host bestimmt, den Sie aufrufen, nicht durch einen Parameter.

4. Ein Live-Konto ohne deviceId oder ein nicht genehmigtes Gerät

Demo ist nachsichtig. Live ist es nicht. Bei einem finanzierten/Live-Konto müssen Sie bei der Token-Anfrage eine stabile deviceId senden, und das Gerät muss über den Bestätigungsablauf genehmigt werden, den Tradovate für die Zwei-Faktor-Sicherheit durchführt. Verpassen Sie das, wird das Live-Token, das Sie zurückerhalten, den Live-Socket nicht autorisieren.

5. Das Token ist abgelaufen

Wenn zuvor alles funktionierte und dann aus dem Nichts 401 zurückgegeben wurde, ist das Token abgelaufen. Access-Token sind zeitlich begrenzt, sodass ein langlebiger Socket irgendwann einen 401 sieht, als wäre er nie autorisiert worden. Das ist ein Erneuerungsproblem, kein Einrichtungsproblem.

Die Lösung, Schritt für Schritt

Live-Konten: die deviceId- und Berechtigungsprüfung

Wenn Demo einwandfrei funktioniert und Sie den 401 nur bei Live erhalten, liegt die Ursache fast immer auf der Geräte-Genehmigungsseite und nicht in Ihrem Code. Zwei Dinge sind zu prüfen.

Stellen Sie zunächst sicher, dass der API-Zugriff auf dem Konto tatsächlich aktiviert ist und der Schlüssel die Berechtigung hat, das zu tun, was Sie verlangen. In der Tradovate-Web-App liegt das unter den Kontoeinstellungen, im Bereich, der das API-Access-Add-on und die Schlüsselberechtigungen verwaltet. (Bestätigen Sie die genaue Bezeichnung in Ihrer aktuellen Version, Wortlaut und Ort dieses Add-on-Bildschirms werden im Laufe der Zeit angepasst.)

Senden Sie zweitens eine deviceId, die über mehrere Durchläufe hinweg gleich bleibt, und genehmigen Sie sie. Live erzwingt gerätebasierte Zwei-Faktor-Sicherheit; eine brandneue oder fehlende deviceId löst einen Genehmigungsschritt aus, der das Token bis zur Klärung außerstande lässt, den Live-Socket zu autorisieren. Erzeugen Sie eine stabile Kennung für Ihre App, verwenden Sie sie jedes Mal wieder und bestätigen Sie sie über die E-Mail, die Tradovate sendet.

Immer noch 401? Diese Checkliste durchgehen

Wenn es funktionierte und dann mitten in der Sitzung kaputtging, springen Sie direkt zur Token-Lebensdauer. Access-Token halten nicht ewig, und ein Socket, der eine Weile offen war, beginnt 401 zu werfen, sobald das dahinterstehende Token abläuft. Erneuern Sie es vor Ablauf, statt auf die Fehler zu warten. Und wenn schon die allererste Token-Anfrage fehlschlägt, gehen Sie zurück und stellen sicher, dass API-Zugriff besteht und ein Schlüssel erzeugt wurde, bevor Sie den Socket überhaupt anfassen.

Die Socket-Installationsarbeit ganz überspringen

Den Auth-Handshake, Heartbeats, die Gerätegenehmigung und die Token-Erneuerung von Hand zu bauen, ist eine Menge beweglicher Teile, nur um eine Order zu routen. Wenn Sie Tradovate mit TradingView-Alerts oder einer Strategie verdrahten, übernimmt PickMyTrade die gesamte Verbindungsebene für Sie, autorisierte Sitzungen, Live-Gerätebehandlung und Token-Erneuerung inklusive, sodass Sie ein Signal senden und es wird gehandelt.