API 401 Unauthorized de Tradovate (jeton expiré)

Vous configurez un bot pour l'API Tradovate, envoyez quelques ordres de démonstration et tout fonctionne parfaitement, puis, au bout d'environ une heure et demie, chaque appel se heurte soudain à un 401 Unauthorized. C'est l'une des erreurs les plus courantes et les plus mal comprises de l'API Tradovate, et la cause est presque toujours la même : votre jeton d'accès a discrètement expiré. Les jetons d'accès Tradovate ont une durée de vie d'environ 90 minutes. Une fois ce délai écoulé, l'API REST et le WebSocket de données de marché cessent tous deux de vous faire confiance. Vous le verrez sous la forme d'un simple statut HTTP 401 Unauthorized, d'un message "Access is denied", ou d'un WebSocket qui envoie brusquement une trame de fermeture et se déconnecte. La solution n'est pas de marteler à nouveau le point de terminaison de connexion, mais de renouveler le jeton avant qu'il n'expire. Des passerelles d'automatisation comme PickMyTrade gèrent ce cycle de vie du jeton pour vous, de sorte que vos alertes continuent de se déclencher même là où un script brut se serait arrêté.

Que signifie « 401 Unauthorized »

Un 401 Unauthorized renvoyé par l'API Tradovate signifie que le serveur a reçu votre requête mais a refusé de l'exécuter parce qu'il n'a pas pu vérifier un jeton d'accès valide et à jour. Il s'agit d'un échec d'authentification, pas d'un problème de droits, ni d'un problème de logique d'ordre. L'API dit essentiellement : “Je ne sais pas qui vous êtes en ce moment.” Côté REST, vous le voyez sous la forme d'un statut HTTP 401. Sur le WebSocket de données de marché et de trading, cela arrive généralement sous la forme d'une trame portant "s":401 avec le texte "Access is denied", souvent suivie de la fermeture du socket.

Voici ce qui déroute la plupart des gens : un jeton d'accès Tradovate est volontairement conçu pour être de courte durée. Lorsque vous vous authentifiez via /auth/accessTokenRequest, la réponse vous fournit un accessToken ainsi qu'un expirationTime, et cette expiration se situe environ 90 minutes plus tard. Pendant cette fenêtre, le jeton est votre clé pour chaque point de terminaison protégé. Dès qu'il expire, la même requête exacte qui fonctionnait une minute plus tôt renvoie un 401, car la clé n'ouvre plus la serrure.

C'est pourquoi cette erreur est si déroutante la première fois qu'elle survient. Rien n'a changé dans votre code, votre clé API et votre secret restent corrects, et pourtant les appels échouent. Le problème, c'est le temps, pas la configuration. Un 401 qui n'apparaît qu'après plus d'une heure de fonctionnement de votre application est la signature d'un jeton expiré.

Principales causes de l'erreur 401 Unauthorized de l'API Tradovate en 2026

1. Le jeton d'accès a expiré (la limite de 90 minutes)

C'est de loin la cause la plus courante. Les jetons d'accès Tradovate ont une durée de vie documentée d'environ 90 minutes à partir de leur création. Si votre bot récupère un jeton une seule fois au démarrage et ne le rafraîchit jamais, chaque requête effectuée après cette marque de 90 minutes renvoie un 401. En pratique, l'échec a tendance à survenir vers la 80e minute, juste au moment où un jeton jamais renouvelé cesse de fonctionner.

2. Renouvellement trop tardif, après l'expiration du jeton

/auth/renewAccessToken ne fonctionne que tant que votre jeton actuel est encore valide. Si vous attendez l'expiration pour renouveler, l'appel de renouvellement lui-même échoue avec un 401, vous essayez d'authentifier un renouvellement avec une clé morte. Une fois qu'un jeton a totalement expiré, vous devez exécuter un nouveau /auth/accessTokenRequest, et non un renouvellement.

3. Un en-tête Authorization mal formé

Même un jeton parfaitement valide est rejeté si vous le présentez incorrectement. Sur les appels REST, l'en-tête doit être Authorization: Bearer <token>, un préfixe Bearer manquant ou un espace superflu suffit à déclencher un 401. Sur le WebSocket, la trame authorize doit être formatée exactement comme le spécifie la documentation actuelle (point de terminaison, id, puis le jeton, avec les séparateurs de ligne vide corrects). Une erreur de formatage produit là aussi la même réponse "Access is denied".

4. Environnement incorrect (jeton de démonstration sur un hôte en direct, ou l'inverse)

Tradovate exploite des environnements de démonstration et en direct distincts. Un jeton émis pour l'hôte de démonstration n'autorise pas les requêtes envoyées à l'hôte en direct, et l'inverse est également vrai. Dirigez un jeton de démonstration valide vers un point de terminaison en direct (ou un jeton en direct vers la démonstration) et cela se traduit par un 401 / accès refusé, même si le jeton lui-même est authentique.

5. Le jeton a été invalidé par une seconde connexion

Les jetons d'accès sont liés à une session. Si un autre processus, un second script, un test manuel ou une nouvelle exécution de votre propre flux de connexion demande un nouveau jeton pour le même compte, cela peut invalider le jeton que votre bot utilise encore. Le bot commence alors à accumuler des erreurs 401 en cours d'exécution, même si “rien n'a changé” de son côté. Et marteler à répétition le point de terminaison de connexion peut déclencher la pénalité de requêtes de Tradovate, ce qui vous retarde encore davantage.

Comment résoudre l'erreur 401 Unauthorized : étape par étape

Résoudre un jeton expiré : renouvelez-le avant son expiration

Résoudre un jeton déjà expiré

Si votre jeton a déjà expiré et que le renouvellement renvoie un 401, arrêtez d'essayer de le renouveler. Exécutez à nouveau un /auth/accessTokenRequest complet pour obtenir un tout nouveau jeton et une nouvelle expiration, puis reprenez la boucle de renouvellement avant expiration décrite ci-dessus. Concevez votre client de sorte qu'un 401 sur n'importe quel appel déclenche une seule réauthentification et une seule nouvelle tentative automatique, et non une boucle infinie, qui peut déclencher des pénalités de limite de requêtes.

Résoudre l'en-tête Authorization

Consignez l'en-tête exact envoyé par votre client et vérifiez qu'il correspond à Authorization: Bearer <token> avec un seul espace après Bearer. Pour les connexions WebSocket, vérifiez que la trame authorize correspond au format actuellement documenté avant de supposer que votre jeton est défectueux. Le moyen le plus rapide d'isoler ce problème est d'effectuer le même appel dans un client REST, Postman ou curl, avec un jeton nouvellement émis. Si cela fonctionne, le problème vient de la façon dont votre code construit la requête, et non du jeton.

Résoudre les incompatibilités d'environnement et d'identifiants

Vérifiez que l'hôte que vous appelez correspond à l'environnement pour lequel votre jeton a été émis (démonstration ou en direct). Vérifiez ensuite que votre clé API, votre secret et vos identifiants d'application sont à jour dans l'espace de gestion de l'API Tradovate, les régénérer ou perdre la synchronisation entraînera également des échecs d'authentification. Connectez-vous à votre compte Tradovate, ouvrez la section accès API / module complémentaire, et vérifiez que votre clé est active avant d'incriminer le jeton.

Tableau de dépannage

Évitez cela avec PickMyTrade

Gérer manuellement une horloge de jeton de 90 minutes est fragile, ratez un renouvellement et votre automatisation devient silencieuse juste au moment où un signal se déclenche. PickMyTrade se positionne entre TradingView et Tradovate et gère le cycle de vie du jeton pour vous :

• Renouvellement automatique des jetons, la connexion est actualisée selon un calendrier, de sorte qu'une expiration de 90 minutes ne fait jamais perdre vos ordres.
• Routage sécurisé par session, une seule connexion gérée par compte évite l'invalidation par connexion en double à l'origine des 401 en cours d'exécution.
• Requêtes sécurisées face aux limites de débit, les appels sont espacés pour respecter les limites de requêtes de Tradovate, afin que vous n'échangiez jamais un 401 résolu contre un délai de pénalité.
• Prise en compte de l'environnement, démonstration et direct restent distincts, de sorte qu'un jeton n'est jamais envoyé au mauvais hôte.

Résultat : vos alertes TradingView atteignent Tradovate sans que vous ayez à écrire ni à surveiller la moindre ligne de code d'authentification.