Erreur 401 de l'API Tradovate en direct : ID d'appareil non approuvé

Vous configurez un bot Tradovate, le regardez fonctionner sans accroc sur le compte démo pendant des jours, puis le pointez vers votre compte en direct financé, et chaque ordre revient avec un 401 avec Access is denied. C'est l'un des obstacles les plus courants rencontrés par les traders API, et ce n'est presque jamais un bug dans votre code. Tradovate en direct applique une règle que la démo ignore silencieusement : chaque requête d'authentification doit porter un deviceId permanent et vérifié, et cet appareil doit être approuvé via un lien envoyé par e-mail avant de pouvoir router de vrais ordres. L'erreur se présente sous deux formes, un simple 401 Access is denied, ou une réponse 200 dont le payload indique failureReason: UnknownReason, failureText: Access is denied, mais la cause profonde est la même : un handshake d'appareil manquant. Voici le diagnostic complet et la solution, ainsi que la façon dont un pont comme PickMyTrade évite entièrement cette procédure d'approbation d'appareil.

Ce que signifie « Access Is Denied »

La réponse Access is denied signifie que Tradovate vous indique que la session ou l'appareil à l'origine de la requête n'a pas été autorisé à agir sur un compte en direct, même si votre nom d'utilisateur, votre mot de passe et votre secret API sont corrects. C'est ce qui rend la situation si déroutante : les mêmes identifiants qui s'authentifient sans problème et placent des ordres en démo échouent soudainement dès que vous passez à l'hôte en direct.

Vous pouvez le voir comme un 401 HTTP net, ou, de façon plus trompeuse, comme un 200 HTTP dont le corps JSON porte un payload d'échec du type [{'s': 200, 'i': 3, 'd': {'failureReason': 'UnknownReason', 'failureText': 'Access is denied'}}]. Seul le direct impose des ID d'appareil vérifiés. C'est l'une des très rares différences entre la simulation et le direct, et la raison principale pour laquelle les 401 apparaissent en direct mais jamais en simulation. Autrement dit, il s'agit d'une barrière de confiance à deux facteurs / appareil, pas d'un corps d'ordre défectueux.

Principales causes d'un 401 en direct

1. Vous ciblez encore l'hôte démo

La cause la plus triviale : l'URL de base n'a jamais été changée. Les tokens démo et les ID de compte démo ne valent rien face au point de terminaison en direct, et inversement. Si vous n'êtes pas passé de demo.tradovateapi.com à live.tradovateapi.com, les requêtes échoueront pour les comptes en direct, tout simplement.

2. Vous n'envoyez pas de deviceId permanent

Le deviceId est une chaîne pouvant compter jusqu'à 64 caractères, destinée à identifier de manière unique et permanente l'appareil physique à l'origine de la requête. La démo ne le vérifie jamais, donc de nombreuses intégrations l'omettent ou génèrent une valeur jetable à chaque exécution. Le direct rejette cela. Régénérer un nouveau deviceId à chaque connexion donne aussi l'impression, à chaque fois, d'un tout nouvel appareil non approuvé, si bien que le 401 ne disparaît jamais.

3. L'appareil n'a jamais été approuvé via le lien envoyé par e-mail

C'est la cause que la plupart des gens ratent. Comme Tradovate traite le deviceId comme faisant partie de son authentification à deux facteurs, un nouvel appareil doit être confirmé hors bande. Vous recevrez un e-mail pour approuver l'ID d'appareil, et tant que vous ne l'approuvez pas en direct, l'accès continue d'être refusé. Pas de clic d'approbation, pas d'accès en direct, un point c'est tout.

4. Vous avez conservé l'accountId ou l'accountSpec de la démo en direct

Vos comptes en direct et démo ne partagent pas le même accountId numérique, et la chaîne accountSpec diffère également (une spec en direct par rapport à une préfixée DEMO). Réutilisez les valeurs démo contre l'hôte en direct et vous obtiendrez le même Access is denied, même une fois l'appareil approuvé.

5. La clé API n'a pas d'accès en écriture aux ordres

Si la clé ou l'application a été provisionnée avec une portée en lecture seule ou données de marché uniquement, le placement d'ordres en direct sera refusé. La clé a besoin du droit complet sur les ordres (écriture), obtenu via le module complémentaire API Access de Tradovate et la configuration de l'application.

Comment corriger le 401 en direct : étape par étape

Corriger un deviceId manquant ou non permanent

Approuver l'appareil via le lien envoyé par e-mail

Changer d'hôte et récupérer à nouveau les valeurs du compte en direct

Confirmer le droit API Access

Tableau de dépannage

Où PickMyTrade s'intègre

Si vous préférez trader vos signaux TradingView en direct sans gérer manuellement les ID d'appareil, les e-mails d'approbation et les changements de point de terminaison, PickMyTrade s'occupe du handshake avec le courtier pour vous :

• Connexion en direct gérée la gestion de la confiance des appareils et des points de terminaison qui fait trébucher les intégrations API brutes se fait en coulisses, de sorte que les ordres en direct sont routés dès la première fois.
• Filtres de droits et de risque respecte l'état de l'accord de données de votre compte et les limites de la prop firm avant même l'envoi d'un ordre.
• Routage sécurisé contre les limites de débit espace le flux d'ordres pour que les appels d'authentification et d'ordres ne soient pas rejetés.
• Synchronisation multi-comptes reproduit le même signal sur plusieurs comptes Tradovate sans avoir à maintenir un handshake d'appareil distinct par bot.