API Tradovate: 'Access is denied' nell'invio dell'ordine

Collega un bot all'API REST di Tradovate, parte il primo ordine live, e arriva Access is denied. Sembra un muro. Le sue credenziali hanno funzionato. L'autenticazione le ha fornito un token. Può persino vedere le sue posizioni. Eppure /order/placeOrder rifiuta ogni esecuzione con la stessa stringa laconica, a volte come 401, a volte come HTTP 200 con {"failureReason":"UnknownReason","failureText":"Access is denied"}. La buona notizia: quasi mai si tratta di un problema di “chiave non valida”. È uno dei quattro errori banali e facilmente risolvibili: l'id account sbagliato, un permesso Orders troppo limitato, l'host demo/live sbagliato, o un flag isAutomated gestito male. Di seguito trova la checklist completa, cosa significa realmente l'errore, ogni causa con una soluzione passo dopo passo, e come PickMyTrade evita del tutto questa categoria di problemi in modo che i suoi alert di TradingView arrivino a Tradovate senza dover eseguire il debug del JSON in apertura.

Cosa significa "Access is denied"

Access is denied è la risposta generica di Tradovate che significa “questa richiesta non è autorizzata a farlo”. La trappola è che non è un errore di autenticazione nel senso comune: può avere un access token perfettamente valido e non scaduto e riceverla comunque. Si verifica nel momento in cui Tradovate verifica se questo token è autorizzato a piazzare questo ordine su questo account. Qualsiasi interruzione in quella catena, un id account che il token non possiede, una API key a cui non sono mai stati concessi i diritti di invio ordini, o un token generato sull'host demo e poi riutilizzato sul live, si manifesta con le stesse tre parole.

Qui contano due tipi di risposta. Un 401 Access Denied puro punta di solito al token o all'host: il token è scaduto, è stato richiesto dalla base URL sbagliata, oppure (in live) il dispositivo non è approvato. Un 200 OK il cui corpo contiene {"failureReason":"UnknownReason","failureText":"Access is denied"} significa che la richiesta si è autenticata correttamente, ma l'ordine stesso è stato rifiutato a livello di permessi, tipicamente per un accountId errato o un permesso Orders mancante.

Poiché entrambe le varianti mostrano la stessa stringa, è facile perdere un'ora a ricontrollare le password quando il vero problema è un singolo campo nel corpo della richiesta. Controlli prima lo stato HTTP, poi analizzi le cause seguenti in ordine.

Principali cause di "Access is denied" sull'invio ordine

1. Sta inviando il nome visualizzato invece dell'id account numerico

Questa è di gran lunga la causa più comune. Il suo account mostra un nome come DEMO1235 o TRAD123456, ed è tentante passare il numero finale come accountId. Ma accountId è l'id entità interno di Tradovate, un valore numerico separato che non ha nulla a che fare con le cifre del nome visualizzato. Se passa quello sbagliato, il token non “possiede” quell'account, quindi l'ordine viene rifiutato.

La soluzione è leggere entrambi gli identificatori da /account/list. Ogni oggetto account restituisce un id (l'id entità numerico da inserire in accountId) e un name (l'etichetta leggibile da inserire in accountSpec). In breve: l'id account non è il numero da cui il suo account risulta chiamato. Non lo codifichi mai in modo fisso, lo recuperi sempre dinamicamente.

2. Il permesso Orders della API key non è Full Access

Tradovate consente di limitare una API key per singola funzionalità. Una key può leggere le posizioni, leggere le informazioni account e leggere la libreria contratti pur avendo Orders impostato al di sotto di Full Access, il che basta esattamente per autenticarsi, elencare gli account e sembrare funzionante, ma viene bloccata nell'istante in cui tenta di piazzare un ordine. La soluzione è diretta: conceda alla key Orders → Full Access nelle impostazioni applicazione/API di Tradovate, quindi riemetta il token in modo che il nuovo permesso venga applicato.

3. Ha generato il token su un host e sta inviando l'ordine su un altro

Tradovate gestisce due ambienti completamente separati con due base URL:

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

Un token richiesto dall'host demo è valido solo verso l'host demo. Se punta quel token verso il /order/placeOrder di live (o viceversa) ottiene Access is denied. L'errore classico è chiamare auth/accessTokenRequest con una base URL malformata o non corrispondente, per poi chiedersi perché ogni ordine successivo fallisca. Verifichi che la chiamata di autenticazione e la chiamata di ordine usino la stessa stringa host, carattere per carattere, e che l'host corrisponda all'account con cui intende realmente operare.

4. isAutomated manca o ha il tipo sbagliato

Se un bot, un algoritmo o qualsiasi processo impersonale attiva l'ordine, le regole CME richiedono isAutomated: true; un essere umano che clicca su un pulsante dell'interfaccia è false. Oltre al semplice includere il flag, presti attenzione al tipo di dato. Quando invia JSON via POST, isAutomated è un booleano (true). Ma se codifica il corpo come form (data= invece di json= in requests di Python), tutto viene serializzato come stringhe, quindi deve essere inviato come stringa "true". Un booleano che ricade silenziosamente su False, o un tipo che il server non riesce a interpretare, la riporta dritta a Access is denied.

5. Formato del simbolo e (in live) un dispositivo non approvato

Due cause meno frequenti completano l'elenco. Primo, il formato del simbolo: passare un contratto scaduto o mal formato, un vecchio codice di scadenza, o un simbolo continuo/di rollover che l'API non riesce a instradare, può leggersi come un rifiuto invece di un chiaro errore di “simbolo non valido”. Passare al contratto del mese frontale attivo (o al suo id contratto) risolve il problema. Secondo, l'id dispositivo in live: il live impone rigorosamente che gli ordini provengano da un deviceId noto e approvato, fornito in auth/accessTokenRequest, mentre il demo lo ignora in gran parte. Se il suo codice piazza ordini in demo ma viene rifiutato solo in live, questo è l'indizio.

Come risolvere "Access is denied": passo dopo passo

Tabella di risoluzione dei problemi

Dove si inserisce PickMyTrade

La maggior parte dei ticket “Access is denied” deriva dalla costruzione manuale della logica di autenticazione e invio ordini. PickMyTrade elimina del tutto questa superficie di rischio intermediando la connessione a Tradovate per lei:

• Autenticazione gestita e instradamento host, l'host demo/live corretto e un token recente e valido vengono gestiti automaticamente, così una sessione scaduta non si presenta mai come un errore di permessi.
• Risoluzione account e permessi, l'id account numerico corretto e il permesso Orders vengono determinati dal suo account collegato, non indovinati da un nome visualizzato.
• Gestione conforme di isAutomated, gli ordini automatizzati vengono contrassegnati correttamente secondo le regole dell'exchange ogni volta, senza insidie booleano-vs-stringa.
• Validazione simbolo e contratto, gli alert vengono mappati su un contratto valido e attivo prima che un ordine venga mai inviato, eliminando la categoria di errore “rifiutato per simbolo non valido”.