API 401 Unauthorized di Tradovate (token scaduto)

Configurate un bot per l'API Tradovate, inviate alcuni ordini demo e tutto funziona senza intoppi, poi, dopo circa un'ora e mezza, ogni chiamata si scontra improvvisamente con un 401 Unauthorized. È uno degli errori più comuni e più fraintesi dell'API Tradovate, e la causa è quasi sempre la stessa: il vostro token di accesso è scaduto silenziosamente. I token di accesso Tradovate durano circa 90 minuti. Una volta trascorso questo tempo, sia l'API REST sia il WebSocket dei dati di mercato smettono di fidarsi di voi. Lo vedrete come un semplice stato HTTP 401 Unauthorized, un messaggio "Access is denied", oppure un WebSocket che invia bruscamente un frame di chiusura e si disconnette. La soluzione non è bombardare di nuovo l'endpoint di login, ma rinnovare il token prima che scada. I bridge di automazione come PickMyTrade gestiscono per voi questo ciclo di vita del token, così i vostri alert continuano a scattare anche dove uno script grezzo si sarebbe fermato.

Cosa significa «401 Unauthorized»

Un 401 Unauthorized dell'API Tradovate significa che il server ha ricevuto la vostra richiesta ma ha rifiutato di eseguirla perché non è riuscito a verificare un token di accesso valido e aggiornato. Si tratta di un errore di autenticazione, non di un problema di permessi né di logica degli ordini. In sostanza l'API sta dicendo: “Non so chi siete in questo momento.” Sul lato REST lo vedrete come uno stato HTTP 401. Sul WebSocket dei dati di mercato e del trading di solito arriva come un frame con "s":401 e il testo "Access is denied", spesso seguito dalla chiusura del socket.

Ecco la parte che confonde: un token di accesso Tradovate è progettato per essere di breve durata. Quando vi autenticate tramite /auth/accessTokenRequest, la risposta vi fornisce un accessToken più un expirationTime, e quella scadenza si colloca circa 90 minuti più avanti. Durante quella finestra il token è la vostra chiave per ogni endpoint protetto. Nel momento in cui scade, la stessa identica richiesta che funzionava un minuto prima restituisce un 401, perché la chiave non apre più la serratura.

Ecco perché l'errore è così sconcertante la prima volta che si presenta. Nel vostro codice non è cambiato nulla, la vostra API key e il secret restano corretti, eppure le chiamate falliscono. Il problema è il tempo, non la configurazione. Un 401 che compare solo dopo che la vostra app è in esecuzione da oltre un'ora è l'impronta caratteristica di un token scaduto.

Principali cause del 401 Unauthorized dell'API Tradovate nel 2026

1. Il token di accesso è scaduto (il limite di 90 minuti)

Questa è di gran lunga la causa più comune. I token di accesso Tradovate hanno, secondo la documentazione, una durata di circa 90 minuti dalla creazione. Se il vostro bot recupera un token una sola volta all'avvio e non lo aggiorna mai, ogni richiesta successiva a quella soglia di 90 minuti restituisce un 401. In pratica l'errore tende a comparire intorno al minuto 80, proprio dove un token mai rinnovato smette di funzionare.

2. Rinnovo troppo tardivo, dopo che il token è già scaduto

/auth/renewAccessToken funziona solo finché il vostro token attuale è ancora valido. Se aspettate la scadenza per rinnovare, la stessa chiamata di rinnovo fallisce con un 401, state cercando di autenticare un rinnovo con una chiave morta. Una volta che un token è completamente scaduto, dovete eseguire un nuovo /auth/accessTokenRequest, non un rinnovo.

3. Un header Authorization malformato

Anche un token perfettamente valido viene rifiutato se lo presentate in modo errato. Nelle chiamate REST l'header deve essere Authorization: Bearer <token>, un prefisso Bearer mancante o uno spazio in più bastano a far scattare un 401. Sul WebSocket, il frame authorize deve essere formattato esattamente come specificato nella documentazione attuale (endpoint, id, poi il token, con i corretti separatori di riga vuota). Un errore di formattazione lì produce la stessa risposta "Access is denied".

4. Ambiente sbagliato (token demo su host live, o viceversa)

Tradovate gestisce ambienti demo e live separati. Un token emesso per l'host demo non autorizza le richieste inviate all'host live, e vale anche il contrario. Puntate un token demo valido verso un endpoint live (o un token live verso demo) e comparirà un 401 / accesso negato, anche se il token stesso è autentico.

5. Il token è stato invalidato da un secondo login

I token di accesso sono legati a una sessione. Se un altro processo, un secondo script, un test manuale o una nuova esecuzione del vostro stesso flusso di login richiede un nuovo token per lo stesso account, può invalidare il token che il vostro bot sta ancora utilizzando. Il bot inizia quindi a collezionare errori 401 a metà esecuzione anche se “nulla è cambiato” dal suo lato. E bombardare ripetutamente l'endpoint di login può attivare la penalità sulle richieste di Tradovate, ritardandovi ulteriormente.

Come risolvere l'errore 401 Unauthorized: passo dopo passo

Risolvere un token scaduto: rinnovatelo prima che scada

Risolvere un token già scaduto

Se il vostro token è già scaduto e il rinnovo restituisce un 401, smettete di provare a rinnovarlo. Eseguite di nuovo un /auth/accessTokenRequest completo per ottenere un token e una scadenza del tutto nuovi, quindi riprendete il ciclo di rinnovo anticipato descritto sopra. Costruite il vostro client in modo che un 401 su qualsiasi chiamata attivi una singola nuova autenticazione e un solo tentativo automatico, non un ciclo infinito, che può far scattare penalità sui limiti di richiesta.

Risolvere l'header Authorization

Registrate l'header esatto inviato dal vostro client e confermate che sia Authorization: Bearer <token> con un solo spazio dopo Bearer. Per le connessioni WebSocket, verificate che il frame authorize corrisponda al formato attualmente documentato prima di presumere che il token sia difettoso. Il modo più rapido per isolare il problema è effettuare la stessa chiamata in un client REST, Postman o curl, con un token appena emesso. Se funziona, il problema sta nel modo in cui il vostro codice costruisce la richiesta, non nel token.

Risolvere le discrepanze tra ambiente e credenziali

Confermate che l'host che state chiamando corrisponda all'ambiente per cui è stato emesso il vostro token (demo o live). Verificate poi che la vostra API key, il secret e le credenziali dell'app siano aggiornati nell'area di gestione API di Tradovate, rigenerarli o perdere la sincronizzazione provocherà anch'esso errori di autenticazione. Accedete al vostro account Tradovate, aprite la sezione accesso API / add-on e confermate che la vostra key sia attiva prima di dare la colpa al token.

Tabella di risoluzione dei problemi

Prevenire tutto questo con PickMyTrade

Gestire manualmente un orologio del token di 90 minuti è fragile, basta perdere un rinnovo e la vostra automazione ammutolisce proprio quando scatta un segnale. PickMyTrade si posiziona tra TradingView e Tradovate e gestisce il ciclo di vita del token per voi:

• Rinnovo automatico del token, la connessione viene aggiornata secondo un programma, così una scadenza di 90 minuti non fa mai perdere i vostri ordini.
• Instradamento sicuro per sessione, una singola connessione gestita per account evita l'invalidazione da login duplicato che causa errori 401 a metà esecuzione.
• Richieste sicure rispetto ai limiti di frequenza, le chiamate sono distanziate nel tempo per rispettare i limiti di richiesta di Tradovate, così non scambiate mai un 401 risolto con un timeout di penalità.
• Consapevolezza dell'ambiente, demo e live restano distinti, così un token non viene mai inviato all'host sbagliato.

Il risultato: i vostri alert di TradingView raggiungono Tradovate senza che dobbiate scrivere né sorvegliare una sola riga di codice di autenticazione.