OSO Tradovate: 'Accesso negato' in Market Replay
Lo stesso bracket OSO che si attiva senza problemi in demo restituisce Access is denied in Market Replay. Replay si autentica in modo diverso, e il rifiuto quasi sempre dipende da come il token è arrivato al socket di replay.
Avete un bracket OSO che si attiva senza problemi in demo. Stesso codice, stesso contratto, stesso body, lo puntate su Market Replay per fare il backtest di una sessione, e Tradovate vi restituisce {"failureReason":"UnknownReason","failureText":"Access is denied"}. Dal vostro lato non è cambiato nulla tranne l'ambiente, quindi sembra un bug di permessi. Non lo è. Replay si autentica in modo diverso da demo e live, e il “negato” quasi sempre si riconduce a una cosa sola: il token non è mai stato presentato correttamente al socket di replay, oppure l'ordine punta a un account che la sessione di replay non possiede. Sistemate il flusso di autenticazione e l'OSO che funziona in demo funzionerà anche in Replay. Ecco esattamente cosa succede e come risolverlo.
Versione breve: Replay non ha un proprio endpoint di autenticazione, una POST a
replay.tradovateapi.com/v1/auth/accessTokenRequestrestituisce semplicemente 404. Richiedete l'access token all'endpoint di autenticazionedemo(olive), apritewss://replay.tradovateapi.com/v1/websocket, inviate un frameauthorizecon quel token, quindi instradate ogni chiamata, compreso il vostro OSO, attraverso lo stesso socket contro l'account che la sessione di replay ha creato.
Come si presenta l'errore
Il segnale è che il body della richiesta è identico byte per byte a uno che funziona. Attivate l'OSO in demo e ottenete un set pulito di id ordine:
-
{"orderId":3696709628,"oso1Id":3696709629,"oso2Id":3696709630}
Inviate lo stesso payload in Replay e, invece degli id, ottenete il rifiuto:
-
{"failureReason":"UnknownReason","failureText":"Access is denied"}
Il contratto è valido per la finestra di replay (diciamo MNQM2 durante una sessione che la copre), il token si è autenticato, e potete persino recuperare i dati dell'account. Solo il piazzamento dell'ordine viene rifiutato. Questo schema, tutto si legge correttamente, la scrittura viene negata, è l'impronta di un problema di scope di autorizzazione, non di una credenziale errata.
Perché Market Replay restituisce "Access Is Denied"
Due particolarità di progettazione dell'ambiente di replay causano quasi tutti questi rifiuti.
Replay non ha un endpoint di autenticazione HTTP
In demo e live siete abituati a un mondo REST: fate una POST a auth/accessTokenRequest, ottenete un token, poi inviate gli ordini con POST a order/placeOrder su HTTPS. L'host di replay non funziona così. Non esiste auth/accessTokenRequest su replay.tradovateapi.com, quindi una POST a https://replay.tradovateapi.com/v1/auth/accessTokenRequest restituisce un 404 Not Found. Le persone vedono quel 404, presumono che l'endpoint sia stato spostato, e iniziano a indovinare URL, quando la vera risposta è che replay non ne ha mai avuto uno.
Il token continua ad arrivare dagli endpoint di autenticazione normali. Poi lo portate al WebSocket di replay e vi autorizzate lì. Tutto ciò che segue, sottoscrizioni ai dati di mercato, controllo dell'orologio e piazzamento ordini, viaggia come messaggi incorniciati su quell'unico socket. Se il vostro OSO continua a partire via HTTPS mentre il vostro token vive sul socket, Tradovate non ha alcuna sessione autorizzata a cui associare l'ordine, e ottenete “Access is denied.”
Ogni sessione di replay crea un account nuovo e usa e getta
Replay non opera sul vostro account demo o live. Quando chiamate replay/initializeClock, Tradovate avvia una sessione e crea un account di replay del tutto nuovo, alimentato con l'initialBalance che passate. Quell'account esiste solo per la sessione e viene scartato quando questa termina. Per ogni utente gira una sola sessione di replay alla volta, e richiamare initializeClock resetta ciò che era in corso.
Ecco la trappola che produce i rifiuti: il vostro OSO deve puntare a quell' account di replay, quello che la sessione attuale ha appena creato, non l'id del vostro account demo, non l'id del vostro account live, e non un id obsoleto di una sessione che avete già resettato. Puntate l'ordine sull'account sbagliato e Tradovate lo rifiuterà con la stessa stringa laconica.
La soluzione, passo dopo passo
Richiedete il token dall'autenticazione demo o live (mai da replay)
Autenticatevi contro un endpoint di ambiente reale e conservate l'accessToken restituito: il lavoro sim/backtest usa https://demo.tradovateapi.com/v1/auth/accessTokenRequest; il lavoro con credenziali live usa https://live.tradovateapi.com/v1/auth/accessTokenRequest. Inviate il set completo di credenziali che il vostro ambiente si aspetta, name, password, appId, appVersion, cid, sec, e, soprattutto su live, un deviceId stabile. Non inviate POST a nessun percorso di autenticazione replay.tradovateapi.com; quella è la trappola del 404.
Aprite il socket di replay e autorizzatevi con quel token
Connettetevi a wss://replay.tradovateapi.com/v1/websocket. Tradovate apre lo stream con un frame di apertura a un solo carattere, la lettera o. Non appena lo vedete, inviate il frame authorize usando il token dello step 1: authorize\n{id}\n\n{accessToken}. Questa forma delimitata da a capo, endpoint, id richiesta, riga vuota, body, è il modo in cui ogni messaggio di replay viene incorniciato. Un authorize riuscito è ciò che concede effettivamente alla vostra sessione il diritto di piazzare ordini sul socket. Saltatelo, e anche un token perfettamente valido lascia il piazzamento ordini non autorizzato.
Inizializzate l'orologio e catturate l'account della sessione
Con il socket autorizzato, impostate la sessione di replay inviando replay/initializeClock con la vostra finestra e velocità: {"startTimestamp":"2019-08-26T16:43:00.000Z","speed":100,"initialBalance":51000}. speed è una percentuale (circa 0–400), e initialBalance finanzia l'account di replay temporaneo. Una volta che l'orologio è in funzione, risolvete l'account legato a questa sessione e conservatene l'id numerico. Questo è l'account a cui il vostro OSO deve fare riferimento in accountId / accountSpec, non l'id che usereste in demo o live.
Inviate l'OSO attraverso il socket di replay, contro quell'account
Ora piazzate il bracket come frame WebSocket sullo stesso socket autorizzato, usando l'account della sessione di replay: order/placeorder\n{id}\n\n{orderBodyJson}. Mantenete lo stesso body OSO che funziona in demo, ma sostituite l'id account di replay catturato allo step 3. Quando l'account e lo step di autorizzazione corrispondono, la risposta passa da failureText a valori reali di orderId / oso1Id / oso2Id.
Mantenete attivi token e socket
Gli access token hanno una vita breve, contate su circa 80-90 minuti. Un'esecuzione di replay lunga può superare la durata del token, e quando scade a metà sessione, l'ordine successivo si legge come un rifiuto. Inviate frame di heartbeat periodici per evitare che il socket resti inattivo, e rinnovate il token prima che scada, non dopo. Trattate un improvviso “Access is denied” nel mezzo di una sessione funzionante come una probabile scadenza, non come un nuovo bug di permessi.
Ricevete ancora "Access Is Denied"? Seguite questa checklist
Se il flusso di autenticazione è corretto e l'OSO ancora non si piazza, controllate questi punti in ordine:
- Discrepanza nell'id account, confermate che l'ordine punta all'account della sessione di replay, non a un id demo/live o a un id obsoleto di una sessione già resettata con un initializeClock più recente.
- Permessi della API key, la chiave con cui vi siete autenticati deve avere Orders concesso, non negato. Una chiave di sola lettura si autentica ed elenca gli account, ma viene bloccata non appena tenta di piazzare un ordine.
- Device id su live, se state generando il token dall'host live, fornite un deviceId stabile e approvato. Demo è permissivo su questo; live no, e le credenziali differiscono tra i due.
- Frame authorize saltato, assicuratevi di aver effettivamente inviato authorize dopo il frame di apertura o e di aver ricevuto un successo prima che qualsiasi ordine parta.
- Limite di una sessione, ricordate che gira una sola sessione di replay per utente. Se un'altra sessione è attiva (dall'interfaccia o da un'esecuzione precedente), la vostra nuova potrebbe resettarla a vostra insaputa.
- Finestra del contratto, il simbolo deve essere valido per la data di replay, quindi usate il contratto che era il front month attivo durante il vostro startTimestamp, non il front month odierno.
Tabella di risoluzione dei problemi
| Sintomo | Causa | Soluzione |
|---|---|---|
| 404 sull'URL di autenticazione replay | Replay non ha un endpoint di autenticazione HTTP | Ottenete il token da demo/live auth/accessTokenRequest, poi autorizzate il socket di replay |
| OSO restituisce {"failureText":"Access is denied"} | Socket mai autorizzato, o ordine puntato sull'account sbagliato | Inviate il frame authorize dopo o; puntate all'account della sessione di replay |
| Funziona in demo, negato in Replay | L'ordine passa ancora via HTTPS invece che sul socket | Inviate order/placeorder come messaggio incorniciato sul WebSocket di replay |
| Timeout o rifiuto subito dopo initializeClock | Uso di un account vecchio da una sessione resettata | Ri-risolvete e usate l'account legato alla sessione attuale |
| Una sessione funzionante rifiuta improvvisamente gli ordini | Access token scaduto a metà esecuzione | Fate heartbeat del socket e rinnovate il token prima di ~80-90 min |
| Negato solo autenticandosi su live | deviceId mancante/non approvato o permesso Orders negato | Fornite un device id stabile approvato; concedete alla chiave l'accesso Orders |
Dove si inserisce PickMyTrade
Cablare manualmente la danza dal token demo al socket di replay è da dove provengono la maggior parte di questi rifiuti, un frame authorize mancato o un id account sbagliato e l'intera sessione rifiuta gli ordini. Se il vostro obiettivo è eseguire una strategia contro Tradovate a partire da alert TradingView invece di sorvegliare i frame WebSocket, PickMyTrade gestisce la connessione per voi: gestisce il token, punta all'account giusto e contrassegna correttamente gli ordini automatizzati in modo che gli ingressi bracket vengano instradati senza che dobbiate debuggare JSON all'apertura.
Instradate i bracket senza toccare l'API
Iniziate la vostra prova gratuita di 5 giorni, collegate i vostri alert e instradate i bracket verso Tradovate senza toccare l'API.
Iniziate la vostra prova gratuita di 5 giorniDomande frequenti
Demo e Replay sono ambienti diversi con un'infrastruttura diversa. In Replay il token deve essere generato dall'endpoint di autenticazione demo o live e poi presentato tramite il WebSocket di replay con un frame authorize. Saltate quello step di autorizzazione, oppure inviate l'ordine contro un account che la sessione non possiede, e lo stesso body che ha successo in demo torna con failureText "Access is denied".
Non esiste un endpoint di autenticazione sull'host di replay. Una POST a https://replay.tradovateapi.com/v1/auth/accessTokenRequest restituisce 404 per progettazione. Richiedete l'access token a https://demo.tradovateapi.com/v1/auth/accessTokenRequest o all'equivalente live, quindi riutilizzate quel token per autorizzare il WebSocket di replay.
Tramite il WebSocket. Una volta autorizzati su wss://replay.tradovateapi.com/v1/websocket, ogni chiamata, incluso order/placeOrder, viene inviata come messaggio incorniciato tipo order/placeorder\n{id}\n\n{body}. Le chiamate HTTP verso l'host di replay non instraderanno i vostri ordini di replay.
replay/initializeClock avvia una sessione di replay e crea un account di replay usa e getta, finanziato per la sessione e scartato al suo termine. Esiste una sola sessione di replay per utente alla volta, e un nuovo initializeClock resetta quella precedente. Gli ordini devono puntare all'account legato alla sessione attuale; un id account obsoleto o demo/live produce errori di accesso negato o timeout.
Sì. Gli access token di Tradovate hanno una vita breve, circa 80-90 minuti. Mantenete attivo il socket con frame di heartbeat periodici e rinnovate il token prima che scada, così una scadenza a metà sessione non si mascheri da rifiuto.
Può contare, specialmente quando vi autenticate contro live invece che demo. Live impone un deviceId stabile e approvato fornito in fase di autenticazione, e le credenziali differiscono tra demo e live. Se Replay funziona con un token demo ma fallisce con uno live, controllate il device id e confermate che il permesso Orders della API key sia concesso, non negato.
Questa guida ha scopo esclusivamente educativo e informativo e non costituisce consulenza finanziaria, di investimento o di trading. Il trading di futures e altri prodotti a leva comporta un rischio sostanziale di perdita e non è adatto a tutti gli investitori. PickMyTrade è una piattaforma di automazione di terze parti indipendente e non è affiliata, sostenuta o sponsorizzata da Tradovate, Inc. Tutti i nomi, i loghi e i marchi correlati sono di proprietà dei rispettivi titolari. Le funzionalità e le procedure della piattaforma cambiano nel tempo, quindi confermate sempre il processo attuale sulla piattaforma e nella documentazione ufficiali di Tradovate prima di agire.