Erreur de jeton OAuth “invalid_client” sur Tradovate
Votre échange de jeton renvoie invalid_client au lieu d'un jeton d'accès. Voici pourquoi les trois champs d'identité de l'application ne correspondent pas, et comment corriger chacun d'eux.
Vous avez un code d'autorisation tout frais en main, vous lancez l'échange de jeton, et au lieu d'un jeton d'accès, vous recevez [invalid_client] client_id, redirect_uri and client_secret do not match existing setup. L'erreur apparaît sous la forme invalid_client, parfois enveloppée dans un code 400 ou 401, et elle bloque net votre intégration Tradovate avant même qu'un seul ordre puisse partir.
Voici la partie rassurante : cette erreur ne signifie presque jamais qu'il y a un problème du côté de Tradovate. Elle signifie que les trois valeurs qui identifient votre application pendant l'échange de jeton ne correspondent pas à ce que vous avez enregistré. Corrigez la divergence et la même requête qui échoue actuellement passera sans problème.
Voici toutes les raisons pour lesquelles cette divergence se produit, dans l'ordre où vous êtes le plus susceptible de les rencontrer, avec les endroits exacts à vérifier dans votre application OAuth et votre code.
Liste de vérification rapide pour l'erreur invalid_client
- Mauvais client_id, recopiez-le depuis votre application OAuth enregistrée ; attention à un espace en début ou un retour à la ligne en fin.
- Mauvais client_secret, si vous l'avez déjà régénéré, l'ancienne valeur est morte ; collez la valeur actuelle partout.
- redirect_uri non identique, il doit correspondre exactement, octet pour octet, à la valeur enregistrée, aussi bien dans l'étape d'autorisation que dans l'échange de jeton.
- Confusion entre live et demo, envoyez la requête de jeton vers le même environnement que celui où votre application a été enregistrée.
- Code d'exemple obsolète, les anciens dépôts d'exemples contiennent des URL de points de terminaison dépassées ; vérifiez les vôtres par rapport à la documentation officielle actuelle.
- Identifiants au mauvais endroit, assurez-vous que grant_type, code, client_id, client_secret et redirect_uri se trouvent bien tous dans le corps de la requête.
Ce que signifie « [invalid_client] client_id, redirect_uri and client_secret do not match existing setup »
OAuth divise votre intégration en deux identités distinctes. La première, c'est vous, le titulaire du compte, prouvé par votre nom d'utilisateur et votre mot de passe. La seconde, c'est votre application, prouvée par un client_id et un client_secret. L'erreur invalid_client concerne entièrement la seconde. C'est la réponse standard OAuth 2.0 pour «l'échec de l'authentification du client», et Tradovate précise exactement quels champs elle a vérifiés : client_id, redirect_uri, et client_secret.
Donc quand vous voyez cette erreur, le code d'autorisation que vous venez de recevoir est généralement valide. Le serveur est arrivé au stade de confirmer l'identité de votre application, a comparé les trois valeurs que vous avez envoyées avec l'enregistrement sauvegardé lors de votre inscription, a trouvé une différence, et a refusé d'aller plus loin. Il ne vous dira pas lequel des trois est en cause. C'est la partie agaçante, et c'est pourquoi la correction se fait par élimination.
La requête qui déclenche cette erreur est votre échange de jeton : un POST vers le point de terminaison de jeton OAuth sur l'hôte de votre environnement (live.tradovateapi.com pour le live, demo.tradovateapi.com pour le demo) portant grant_type=authorization_code, le code, et les trois champs d'identité. Un succès renvoie un access_token et un expires_in. Un échec renvoie error et error_description, et ici, cette erreur est invalid_client.
Principales causes de l'erreur invalid_client
1. Le client_id ne correspond pas à votre application enregistrée
C'est la cause la plus simple et la plus facile à négliger. Le client_id dans votre requête de jeton doit être celui que Tradovate a attribué lors de l'enregistrement de votre application OAuth. Les gens se trompent souvent sur de petits détails : coller le nom de l'application au lieu de son identifiant, récupérer un identifiant d'une autre application, ou traîner un espace invisible ou un retour à la ligne en copiant. Les espaces superflus sont les plus sournois, car la valeur a l'air correcte dans votre éditeur. Recopiez l'identifiant directement depuis l'écran d'enregistrement et supprimez les espaces superflus.
2. Le client_secret est incorrect ou a été régénéré
Le client_secret est la partie « mot de passe » de l'identité de votre application, et il doit correspondre exactement. Le piège classique, c'est la régénération : vous avez cliqué sur «régénérer le secret» à un moment donné pour le renouveler, la plateforme en a émis un nouveau, et l'ancienne valeur est désormais définitivement invalide. Si votre code, votre fichier .env, ou votre configuration de déploiement contient encore l'ancien secret, chaque échange renvoie invalid_client. La même chose se produit si vous n'avez en réalité jamais généré de secret et que vous envoyez une valeur vide ou un espace réservé.
3. Le redirect_uri ne correspond pas octet pour octet
C'est la cause qui fait perdre le plus de temps, car les URI semblent identiques au premier coup d'œil. Le redirect_uri doit être identique à trois endroits : la valeur enregistrée sur votre application, la valeur dans votre requête d'autorisation, et la valeur dans votre échange de jeton. Identique signifie caractère pour caractère. Tout ceci compte comme différent :
- Une barre oblique finale sur l'un mais pas sur l'autre (
/callbackvs/callback/). -
httpà un endroit,httpsà un autre. - Un numéro de port présent ici, absent là (
localhost:3030vslocalhost). - Une casse différente n'importe où dans le chemin.
-
localhostà un endroit et127.0.0.1à un autre.
N'importe laquelle de ces différences pousse Tradovate à traiter la redirection comme non enregistrée et à l'intégrer dans la réponse invalid_client.
4. Vous avez enregistré votre application sur un environnement et vous appelez l'autre
Une application OAuth est liée à un seul environnement. Enregistrez-la sur demo et son client_id et son client_secret n'existent que côté demo. Si votre URL d'autorisation ou votre échange de jeton pointe vers l'hôte live alors que l'application vit sur demo, ou l'inverse, les identifiants n'y sont tout simplement pas trouvés, et vous obtenez invalid_client. Confirmez dans quel environnement vous avez enregistré l'application, puis assurez-vous que l'étape d'autorisation et le point de terminaison de jeton ciblent tous deux ce même environnement.
5. Vous exécutez du code d'exemple obsolète
Les exemples OAuth vieillissent. Un ancien projet d'exemple peut contenir des URL de points de terminaison, un redirect_uri codé en dur, ou une structure de requête qui ne correspond plus à une application fraîchement enregistrée. Si vous avez cloné un tutoriel et qu'il «ne fonctionne tout simplement pas», ne présumez pas que vos identifiants sont faux ; vérifiez que les points de terminaison et le corps de la requête dans ce code correspondent toujours à la documentation officielle Tradovate actuelle avant de passer une heure à déboguer votre secret.
6. Les identifiants sont absents ou mal placés dans la requête
Chaque champ vérifié par le serveur doit effectivement arriver, au bon endroit, dans le bon format. Votre POST de jeton a besoin de grant_type=authorization_code, du code, de client_id, client_secret et redirect_uri, envoyés dans le corps de la requête tel que le spécifie la documentation actuelle. Omettez l'un des trois champs d'identité, ou envoyez le corps dans un format que le point de terminaison n'attend pas, et l'application ne peut pas être authentifiée, ce qui se traduit par invalid_client.
Comment corriger l'erreur invalid_client : étape par étape
Recopiez le client_id et le client_secret
Ouvrez l'écran d'enregistrement de votre application OAuth (dans la section API Access de vos paramètres). Copiez le client_id à nouveau et collez-le dans votre configuration, puis supprimez tout espace superflu en début ou en fin. Faites de même pour le client_secret ; si vous n'êtes pas certain que celui en cours correspond à votre code, régénérez-le, mettez à jour tous les endroits où il est stocké, puis redéployez.
Notez le redirect_uri enregistré
Notez le redirect_uri exact enregistré sur l'application afin de pouvoir le comparer ensuite à votre code.
Fixez le redirect_uri dans une seule constante
Définissez une seule constante REDIRECT_URI par environnement dans votre code. Utilisez cette constante exacte pour construire l'URL d'autorisation et le corps de l'échange de jeton, sans jamais la retaper. Comparez-la à la valeur enregistrée, en surveillant les barres obliques, le schéma, le port et la casse, et corrigez le côté erroné pour que les trois copies soient identiques.
Confirmez l'environnement et les points de terminaison
Déterminez dans quel environnement l'application est enregistrée, live ou demo. Pointez la requête d'autorisation vers https://trader.tradovate.com/oauth avec response_type=code, votre client_id, et le redirect_uri correspondant. Envoyez l'échange de jeton vers le point de terminaison OAuth sur l'hôte du même environnement, live.tradovateapi.com ou demo.tradovateapi.com, en utilisant le chemin exact indiqué dans la référence API actuelle.
Relancez le flux de bout en bout
Demandez un tout nouveau code d'autorisation, puis échangez-le immédiatement. Les codes sont à usage unique, donc ne réutilisez pas celui qui a déjà échoué.
Tableau de dépannage
| Erreur | Signification | Correction |
|---|---|---|
[invalid_client] client_id, redirect_uri and client_secret do not match existing setup | Un ou plusieurs des trois champs d'identité de l'application ne correspondent pas à l'application OAuth enregistrée. | Recopiez client_id et client_secret ; rendez redirect_uri identique aux trois endroits. |
invalid_client (sans détail) | Échec de l'authentification du client, l'application n'a pas pu être identifiée. | Vérifiez que client_id/secret sont corrects et envoyés dans le corps de la requête, et non laissés vides. |
invalid_grant | Le code d'autorisation est expiré, déjà utilisé, ou lié à un redirect_uri différent. | Demandez un nouveau code et échangez-le immédiatement avec le redirect_uri correspondant. |
redirect_uri_mismatch | Le redirect_uri ne correspond pas à celui de l'application. | Alignez le schéma, l'hôte, le port, le chemin et la barre oblique finale, octet pour octet. |
unsupported_grant_type | La valeur grant_type est absente ou mal orthographiée. | Envoyez exactement grant_type=authorization_code. |
| Identifiants valides sur demo, en échec sur live | Application enregistrée dans un environnement, requête envoyée vers l'autre. | Ciblez l'URL d'autorisation et le point de terminaison de jeton vers l'environnement propre à l'application. |
Évitez ce problème avec PickMyTrade
Toute la poignée de main OAuth existe pour permettre à un logiciel de trader votre compte à votre place. Si ce logiciel est PickMyTrade, vous ne touchez jamais à un client_secret ni ne déboguez un redirect_uri, vous connectez votre compte Tradovate une seule fois et acheminez vos alertes TradingView vers des ordres réels à partir de là.
- Connexion de compte guidée, liez Tradovate via un parcours guidé au lieu de coder manuellement un échange de jeton.
- Sessions gérées, le cycle de vie du jeton et son renouvellement s'exécutent en coulisses, donc vous n'avez aucun code d'authentification à maintenir en vie.
- Routage sensible à l'environnement, demo et live restent séparés afin que les identifiants ne se mélangent jamais.
- Synchronisation multi-compte, reproduisez la même alerte sur plusieurs comptes sans configurer OAuth pour chacun.
Faites l'impasse sur la poignée de main OAuth
Connectez Tradovate à PickMyTrade une seule fois et acheminez vos alertes TradingView vers des ordres réels, sans client_secret ni redirect_uri à déboguer.
Démarrez votre essai gratuit de 5 joursQuestions fréquentes
Cela signifie que Tradovate n'a pas pu authentifier votre application pendant l'échange de jeton. Le message complet, [invalid_client] client_id, redirect_uri and client_secret do not match existing setup, vous indique qu'au moins une de ces trois valeurs dans votre POST ne correspond pas à l'enregistrement stocké pour votre application OAuth enregistrée. Le code d'autorisation était valide ; c'est l'identité de l'application qui a échoué.
Votre connexion web utilise votre nom d'utilisateur et votre mot de passe. L'échange de jeton OAuth utilise un ensemble d'identifiants distinct, client_id et client_secret, qui appartiennent à l'application que vous avez enregistrée, et non à votre compte de trading. Une connexion web parfaite ne dit rien sur l'exactitude de ces identifiants d'application, donc les deux réussissent ou échouent indépendamment.
Octet pour octet. Le redirect_uri dans la requête d'autorisation et celui dans l'échange de jeton doivent tous deux correspondre à la valeur enregistrée sur l'application, caractère pour caractère. Une barre oblique finale, http contre https, un port différent, ou un changement de casse comptent tous comme une divergence. Définissez une seule constante et réutilisez-la partout.
Oui. Une application OAuth est enregistrée pour un seul environnement. Si vous l'avez enregistrée sur demo mais que vous envoyez la requête de jeton vers l'hôte live, ou l'inverse, les identifiants ne sont pas trouvés et vous obtenez invalid_client. Pointez l'URL d'autorisation et le point de terminaison de jeton vers le même environnement où votre application a été créée.
Régénérer un secret annule instantanément l'ancien. Si votre code, votre fichier d'environnement, ou votre déploiement envoie encore l'ancienne valeur, chaque échange échoue. Copiez le nouveau secret dans tous les endroits où il est stocké, redéployez, et videz toute configuration mise en cache pour qu'aucune ne continue à transmettre la chaîne retirée.
Non, et la différence vous oriente vers le véritable problème. invalid_client concerne l'identité de l'application : un client_id erroné, un client_secret erroné, ou un redirect_uri qui ne correspond pas. invalid_grant concerne le code d'autorisation : il a expiré, il a déjà été utilisé, ou il a été émis pour un redirect_uri différent. Si vous voyez invalid_grant, demandez un nouveau code au lieu de revérifier votre secret.
OAuth avec client_id et client_secret est une voie possible, et c'est celle qui déclenche invalid_client. Tradovate prend également en charge une requête directe de jeton d'accès utilisant un identifiant d'application et un secret API. Si vous automatisez votre propre compte et n'avez pas besoin de faire passer d'autres utilisateurs par un écran de consentement, la requête directe de jeton est souvent plus simple et évite entièrement la poignée de main OAuth.
Ouvrez la zone d'applications ou de paramètres de votre compte, allez dans la section API Access, et retrouvez l'enregistrement OAuth que vous avez créé. Le client_id et le client_secret s'y trouvent, ainsi que le redirect_uri que vous avez enregistré. Les libellés évoluent avec le temps, donc si vous ne voyez pas d'onglet API Access, consultez la disposition actuelle des paramètres ou la documentation officielle pour trouver l'écran équivalent.
Ce guide est fourni à des fins éducatives et informatives uniquement et ne constitue pas un conseil financier, d'investissement ou de trading. Le trading de contrats à terme et d'autres produits à effet de levier comporte un risque de perte substantiel et ne convient pas à tous les investisseurs. PickMyTrade est une plateforme d'automatisation tierce indépendante et n'est affiliée à, approuvée par, ou sponsorisée par Tradovate, Inc. Tous les noms, logos et marques associés sont la propriété de leurs détenteurs respectifs. Les fonctionnalités et étapes de la plateforme évoluent au fil du temps ; vérifiez toujours le processus actuel dans la documentation officielle de la plateforme avant d'agir.