Tradovate OSO: 'Zugriff verweigert' im Market Replay

Dieselbe OSO-Bracket-Order, die in der Demo einwandfrei ausgelöst wird, liefert im Market Replay Access is denied zurück. Replay authentifiziert sich anders, und die Ablehnung lässt sich fast immer darauf zurückführen, wie das Token beim Replay-Socket ankam.

Geprüft vom PickMyTrade Trading Systems Team Zuletzt aktualisiert 8. Juli 2026

· 8 Minuten Lesezeit

Tradovate OSO-Order mit Access is denied im Market Replay neben einer erfolgreichen Demo-Antwort mit Order-IDs

Sie haben eine OSO-Bracket-Order, die in der Demo einwandfrei auslöst. Gleicher Code, gleicher Kontrakt, gleicher Body, Sie richten sie auf Market Replay, um eine Session zurückzutesten, und Tradovate liefert Ihnen {"failureReason":"UnknownReason","failureText":"Access is denied"}. Auf Ihrer Seite hat sich außer der Umgebung nichts geändert, also fühlt es sich wie ein Berechtigungsfehler an. Ist es aber nicht. Replay authentifiziert sich anders als Demo und Live, und “abgelehnt” lässt sich fast immer auf eines zurückführen: Das Token wurde dem Replay-Socket nicht korrekt übergeben, oder die Order zielt auf ein Konto, das der Replay-Session nicht gehört. Bringen Sie den Auth-Ablauf in Ordnung, und die OSO, die in der Demo funktioniert, funktioniert auch im Replay. Hier ist genau, was passiert und wie Sie es beheben.

Kurzfassung: Replay hat keinen eigenen Auth-Endpoint, ein POST an replay.tradovateapi.com/v1/auth/accessTokenRequest liefert nur einen 404. Fordern Sie das Access Token vom demo- (oder live-) Auth-Endpoint an, öffnen Sie wss://replay.tradovateapi.com/v1/websocket, senden Sie einen authorize-Frame mit diesem Token, und leiten Sie danach jeden Aufruf, einschließlich Ihrer OSO, über dasselbe Socket gegen das Konto, das die Replay-Session erstellt hat.

Wie der Fehler aussieht

Das Erkennungsmerkmal: Der Request-Body ist byte-für-byte identisch mit einem, der funktioniert. Lösen Sie die OSO in der Demo aus, erhalten Sie einen sauberen Satz Order-IDs zurück:

{"orderId":3696709628,"oso1Id":3696709629,"oso2Id":3696709630}

Senden Sie dieselbe Payload im Replay, erhalten Sie statt IDs die Ablehnung:

{"failureReason":"UnknownReason","failureText":"Access is denied"}

Der Kontrakt ist für das Replay-Fenster gültig (etwa MNQM2 während einer Session, die es abdeckt), das Token wurde authentifiziert, und Sie können sogar Kontodaten abrufen. Nur die Orderplatzierung wird verweigert. Dieses Muster, alles liest sich einwandfrei, das Schreiben wird verweigert, ist der Fingerabdruck eines Autorisierungs-Scope-Problems, nicht eines fehlerhaften Credentials.

Warum Market Replay "Access Is Denied" wirft

Zwei Design-Eigenheiten der Replay-Umgebung verursachen fast alle diese Ablehnungen.

Replay hat keinen HTTP-Auth-Endpoint

Bei Demo und Live sind Sie eine REST-Welt gewohnt: Sie senden ein POST an auth/accessTokenRequest, erhalten ein Token, und senden dann Orders per POST an order/placeOrder über HTTPS. Der Replay-Host funktioniert nicht so. Es gibt kein auth/accessTokenRequest auf replay.tradovateapi.com, also liefert ein POST an https://replay.tradovateapi.com/v1/auth/accessTokenRequest einen 404 Not Found. Leute sehen diesen 404, nehmen an, der Endpoint sei verschoben worden, und beginnen, URLs zu erraten, obwohl die eigentliche Antwort ist, dass Replay nie einen hatte.

HTTP-404-Not-Found-Antwort beim POST an den Tradovate-Replay-Auth-Access-Token-Endpoint

Das Token kommt weiterhin von den normalen Auth-Endpoints. Sie übertragen es dann zum Replay-WebSocket und autorisieren dort. Alles danach, Marktdaten-Abonnements, Clock-Steuerung und Orderplatzierung, läuft als geframte Nachrichten über dieses eine Socket. Wenn Ihre OSO weiterhin per HTTPS hinausgeht, während Ihr Token auf dem Socket lebt, hat Tradovate keine autorisierte Session, der die Order zugeordnet werden kann, und Sie erhalten “Access is denied.”

Jede Replay-Session baut ein frisches Wegwerf-Konto

Replay handelt nicht mit Ihrem Demo- oder Live-Konto. Wenn Sie replay/initializeClock aufrufen, startet Tradovate eine Session und erstellt ein brandneues Replay-Konto, ausgestattet mit dem initialBalance, den Sie übergeben. Dieses Konto existiert nur für die Session und wird verworfen, wenn die Session endet. Pro Benutzer läuft nur eine Replay-Session gleichzeitig, und ein erneuter Aufruf von initializeClock setzt zurück, was gerade lief.

Hier ist der Haken, der Ablehnungen erzeugt: Ihre OSO muss auf dieses Replay-Konto zielen, das, das die aktuelle Session gerade geprägt hat, nicht Ihre Demo-Konto-ID, nicht Ihre Live-Konto-ID und nicht eine veraltete ID aus einer Session, die Sie bereits zurückgesetzt haben. Zielen Sie die Order auf das falsche Konto, verweigert Tradovate sie mit derselben knappen Zeichenkette.

Die Lösung, Schritt für Schritt

Token von Demo- oder Live-Auth anfordern (niemals Replay)

Authentifizieren Sie sich gegen einen echten Umgebungs-Endpoint und behalten Sie das zurückgegebene accessToken: Sim-/Backtest-Arbeit nutzt https://demo.tradovateapi.com/v1/auth/accessTokenRequest; Arbeit mit Live-Credentials nutzt https://live.tradovateapi.com/v1/auth/accessTokenRequest. Senden Sie den vollständigen Credential-Satz, den Ihre Umgebung erwartet, name, password, appId, appVersion, cid, sec, und, besonders auf Live, eine stabile deviceId. Senden Sie kein POST an einen replay.tradovateapi.com-Auth-Pfad; das ist die 404-Falle.

Replay-Socket öffnen und mit diesem Token autorisieren

Verbinden Sie sich mit wss://replay.tradovateapi.com/v1/websocket. Tradovate öffnet den Stream mit einem einzelnen Zeichen als Open-Frame, dem Buchstaben o. Sobald Sie ihn sehen, senden Sie den Authorize-Frame mit dem Token aus Schritt 1: authorize\n{id}\n\n{accessToken}. Diese durch Zeilenumbrüche getrennte Form, Endpoint, Request-ID, Leerzeile, Body, ist, wie jede Replay-Nachricht geframt wird. Ein erfolgreicher Authorize gewährt Ihrer Session erst das Recht, Orders über das Socket zu platzieren. Überspringen Sie ihn, bleibt selbst ein perfekt gültiges Token für die Orderplatzierung nicht autorisiert.

Clock initialisieren und das Konto der Session erfassen

Mit autorisiertem Socket richten Sie die Replay-Session ein, indem Sie replay/initializeClock mit Ihrem Fenster und Ihrer Geschwindigkeit senden: {"startTimestamp":"2019-08-26T16:43:00.000Z","speed":100,"initialBalance":51000}. speed ist ein Prozentsatz (etwa 0–400), und initialBalance finanziert das temporäre Replay-Konto. Sobald die Clock läuft, lösen Sie das mit dieser Session verknüpfte Konto auf und merken sich dessen numerische ID. Dies ist das Konto, auf das Ihre OSO in accountId / accountSpec verweisen muss, nicht die ID, die Sie in Demo oder Live verwenden würden.

OSO über das Replay-Socket senden, gegen dieses Konto

Platzieren Sie die Bracket-Order nun als WebSocket-Frame auf demselben autorisierten Socket, unter Verwendung des Kontos der Replay-Session: order/placeorder\n{id}\n\n{orderBodyJson}. Behalten Sie denselben OSO-Body bei, der in der Demo funktioniert, tauschen Sie aber die in Schritt 3 erfasste Replay-Konto-ID ein. Stimmen Konto und Autorisierungsschritt überein, wechselt die Antwort von failureText zurück zu echten orderId / oso1Id / oso2Id-Werten.

Token und Socket am Leben halten

Access Tokens sind kurzlebig, rechnen Sie mit etwa 80 bis 90 Minuten. Ein langer Replay-Lauf kann das Token überdauern, und wenn es mitten in der Session verfällt, liest sich die nächste Order als Ablehnung. Senden Sie regelmäßige Heartbeat-Frames, damit das Socket nicht in den Leerlauf geht, und erneuern Sie das Token, bevor es abläuft, nicht danach. Behandeln Sie ein plötzliches “Access is denied” mitten in einer funktionierenden Session als wahrscheinlichen Ablauf, nicht als neuen Berechtigungsfehler.

Tradovate-Replay-WebSocket mit dem Open-Frame gefolgt von einem Authorize-Frame, der das Demo-Access-Token trägt

Tradovate-Replay-initializeClock-Antwort und ein order/placeOrder-Frame, das OSO-Order-IDs auf dem Replay-Socket zurückgibt

Immer noch "Access Is Denied"? Diese Checkliste abarbeiten

Wenn der Auth-Ablauf stimmt und die OSO sich immer noch nicht platzieren lässt, gehen Sie diese Punkte der Reihe nach durch:

Konto-ID-Mismatch, prüfen Sie, ob die Order auf das Konto der Replay-Session zielt, nicht auf eine Demo-/Live-ID oder eine veraltete ID aus einer Session, die Sie bereits mit einem neueren initializeClock zurückgesetzt haben.
API-Key-Berechtigungen, der Key, mit dem Sie sich authentifiziert haben, muss Orders gewährt haben, nicht auf verweigert gesetzt sein. Ein Nur-Lese-Key authentifiziert sich und listet Konten auf, wird aber blockiert, sobald er versucht, eine Order zu platzieren.
Device-ID auf Live, wenn Sie das Token vom Live-Host prägen, liefern Sie eine stabile, genehmigte deviceId. Demo ist hierbei nachsichtig; Live nicht, und die Credentials unterscheiden sich zwischen beiden.
Authorize-Frame übersprungen, stellen Sie sicher, dass Sie authorize tatsächlich nach dem o-Open-Frame gesendet haben und einen Erfolg zurückerhalten haben, bevor eine Order hinausgeht.
Ein-Session-Limit, denken Sie daran, dass nur eine Replay-Session pro Benutzer läuft. Wenn eine andere Session aktiv ist (aus der UI oder einem vorherigen Lauf), setzt Ihre neue diese möglicherweise unter Ihnen zurück.
Kontrakt-Fenster, das Symbol muss für das Replay-Datum gültig sein, verwenden Sie also den Kontrakt, der während Ihres startTimestamp der aktive Frontmonat war, nicht den heutigen Frontmonat.

Troubleshooting-Tabelle

Symptom	Ursache	Lösung
404 bei der Replay-Auth-URL	Replay hat keinen HTTP-Auth-Endpoint	Token von demo/live auth/accessTokenRequest holen, dann das Replay-Socket autorisieren
OSO liefert {"failureText":"Access is denied"}	Socket nie autorisiert, oder Order auf falsches Konto gerichtet	Authorize-Frame nach o senden; auf das Konto der Replay-Session zielen
Funktioniert in Demo, abgelehnt in Replay	Order geht weiterhin per HTTPS statt über das Socket	order/placeorder als geframte Nachricht auf dem Replay-WebSocket senden
Timeout oder Ablehnung direkt nach initializeClock	Verwendung eines alten Kontos aus einer zurückgesetzten Session	Konto der aktuellen Session neu auflösen und verwenden
Eine funktionierende Session verweigert plötzlich Orders	Access Token mitten im Lauf abgelaufen	Socket per Heartbeat am Leben halten und Token vor ~80–90 Min erneuern
Nur bei Authentifizierung auf Live abgelehnt	Fehlende/nicht genehmigte deviceId oder verweigerte Orders-Berechtigung	Stabile genehmigte Device-ID liefern; dem Key Orders-Zugriff gewähren

Wo PickMyTrade ansetzt

Der manuelle Aufbau des Demo-Token-zu-Replay-Socket-Tanzes ist die Quelle der meisten dieser Ablehnungen, ein übersehener authorize-Frame oder eine falsche Konto-ID, und die ganze Session verweigert Orders. Wenn Ihr Ziel ist, eine Strategie über TradingView-Alerts gegen Tradovate laufen zu lassen, statt WebSocket-Frames zu hüten, vermittelt PickMyTrade die Verbindung für Sie: Es verwaltet das Token, zielt auf das richtige Konto und markiert automatisierte Orders korrekt, sodass Bracket-Entries routen, ohne dass Sie beim Opening JSON debuggen müssen.

Brackets routen, ohne die API anzufassen

Starten Sie Ihre kostenlose 5-Tage-Testversion, verknüpfen Sie Ihre Alerts und routen Sie Brackets zu Tradovate, ohne die API anzufassen.

Starten Sie Ihre kostenlose 5-Tage-Testversion

Häufig gestellte Fragen

Demo und Replay sind unterschiedliche Umgebungen mit unterschiedlicher Verkabelung. Im Replay muss das Token vom Demo- oder Live-Auth-Endpoint geprägt und dann über das Replay-WebSocket mit einem Authorize-Frame präsentiert werden. Überspringen Sie diesen Authorize-Schritt, oder senden Sie die Order gegen ein Konto, das der Session nicht gehört, kommt derselbe Body, der in der Demo erfolgreich ist, mit failureText "Access is denied" zurück.

Es gibt keinen Auth-Endpoint auf dem Replay-Host. Ein POST an https://replay.tradovateapi.com/v1/auth/accessTokenRequest liefert absichtlich 404. Fordern Sie das Access Token von https://demo.tradovateapi.com/v1/auth/accessTokenRequest oder dem Live-Äquivalent an und verwenden Sie dieses Token dann, um das Replay-WebSocket zu autorisieren.

Über das WebSocket. Sobald Sie auf wss://replay.tradovateapi.com/v1/websocket autorisiert sind, wird jeder Aufruf, einschließlich order/placeOrder, als geframte Nachricht wie order/placeorder\n{id}\n\n{body} gesendet. HTTP-Aufrufe an den Replay-Host routen Ihre Replay-Orders nicht.

replay/initializeClock startet eine Replay-Session und erstellt ein Wegwerf-Replay-Konto, das für die Session finanziert und bei deren Ende verworfen wird. Pro Benutzer existiert nur eine Replay-Session gleichzeitig, und ein neues initializeClock setzt die vorherige zurück. Orders müssen auf das mit der aktuellen Session verknüpfte Konto zielen, eine veraltete oder Demo-/Live-Konto-ID erzeugt Access-denied- oder Timeout-Fehler.

Ja. Tradovate-Access-Tokens sind kurzlebig, etwa 80 bis 90 Minuten. Halten Sie das Socket mit regelmäßigen Heartbeat-Frames am Leben und erneuern Sie das Token, bevor es abläuft, damit ein Ablauf mitten in der Session nicht als Ablehnung erscheint.

Das kann sie, besonders wenn Sie sich gegen Live statt gegen Demo authentifizieren. Live erzwingt eine stabile, genehmigte deviceId bei der Authentifizierung, und die Credentials unterscheiden sich zwischen Demo und Live. Funktioniert Replay mit einem Demo-Token, schlägt aber mit einem Live-Token fehl, prüfen Sie die Device-ID und bestätigen Sie, dass die Orders-Berechtigung des API-Keys gewährt und nicht verweigert ist.