Tradovate addEntitlementSubscription : compte en direct requis

Vous avez provisionné un utilisateur via l'API Tradovate, le compte est créé, tout semble correct, puis votre appel à addEntitlementSubscription renvoie toujours Live account is required et l'entitlement de données de marché n'est jamais attribué. C'est l'une des réponses les plus déroutantes de tout le flux de provisioning, car le compte existe bel et bien et le message vous oriente dans la mauvaise direction. Voici la version courte : cette erreur signifie presque toujours que l'utilisateur n'a pas encore signé l'accord de données de marché non professionnel. Faites signer cet accord, confirmez qu'il est synchronisé, et le même appel passera. Voici le diagnostic complet, l'ordre exact dans lequel les appels doivent s'exécuter, et comment un pont comme PickMyTrade évite toute cette gymnastique d'entitlements.

Ce que signifie réellement "Un compte en direct est requis"

Prenez le message au pied de la lettre et vous perdrez tout un après-midi. La réponse ne dit pas que le compte est manquant, elle indique que le compte n'est pas encore éligible à recevoir un entitlement de données de marché en direct. Et la raison la plus courante, de loin, est un accord de données de marché manquant. Tradovate, comme tout courtier en futures, doit avoir au dossier un accord de données de marché CME signé avant de pouvoir fournir à un utilisateur des données de marché en temps réel. Pas d'accord, pas d'entitlement, et l'API signale cet écart avec la chaîne brute Live account is required.

Un détail fait trébucher beaucoup d'intégrations : la requête n'échoue pas avec une erreur HTTP. Elle renvoie HTTP 200, et le vrai problème se trouve dans le corps JSON sous la forme d'une valeur errorText. Si votre script de provisioning se contente de vérifier response.status === 200 et poursuit, il enregistrera un succès alors que l'entitlement n'a jamais été attribué silencieusement, et vous ne le découvrirez que lorsque l'utilisateur ouvrira un graphique avec un symbole vide, retardé ou sans cotation. Lisez toujours le corps de la réponse.

Pourquoi l'accord est le véritable obstacle

Les données de futures en temps réel ne viennent pas sans formalités. CME Group exige que chaque utilisateur final recevant des données en direct soit classifié et accepte les conditions de données de marché de la bourse, c'est l'“accord” dont il est question ici. Les utilisateurs déclarent s'ils sont professionnels ou non professionnels, et l'immense majorité des traders particuliers relèvent de la catégorie non professionnelle. Cette déclaration, associée aux conditions acceptées, est ce qui débloque l'entitlement que votre appel API tente d'attribuer.

Tant que l'utilisateur n'a pas terminé cette étape, le compte peut techniquement exister, il peut même s'agir d'un compte simulé ou d'évaluation, mais il ne peut légalement pas recevoir de données de marché en direct. L'attribution de l'entitlement n'a donc rien de valide auquel s'accrocher, et Tradovate la refuse. C'est la même cause première derrière toute une famille de symptômes en aval : symboles qui restent retardés, graphiques sans cotations, et ordres rejetés pour “aucune cotation disponible”. L'accord est en amont de tout cela.

Professionnel ou non professionnel, en bref

Le statut non professionnel couvre généralement les particuliers qui négocient leur propre argent à des fins personnelles. Le statut professionnel s'applique à certains usages commerciaux, de conseil ou de redistribution de données et entraîne des frais de bourse nettement plus élevés. C'est l'utilisateur qui le déclare, et il est responsable de le déclarer avec exactitude. Si un utilisateur n'est pas sûr de son statut, orientez-le vers les critères actuels de la bourse plutôt que de deviner, la différence de frais est réelle et les règles évoluent.

La solution : faire signer l'accord, puis attribuer

Étape 1 : faites signer à l'utilisateur l'accord de données de marché non professionnel

C'est l'étape qui résout l'erreur. L'accord est présenté dans la plateforme Tradovate à laquelle l'utilisateur se connecte, généralement lors de la première connexion, dans la zone compte ou accords, ou au moment où il essaie d'activer les données de marché. L'utilisateur le consulte, déclare le statut non professionnel et l'accepte. Le libellé exact du menu varie selon les versions de la plateforme, donc si vous documentez cela pour vos propres utilisateurs, confirmez l'intitulé actuel dans l'application en direct plutôt que de figer un ancien chemin.

Étape 2 : ajoutez les coordonnées de l'utilisateur

Avant que l'entitlement ne s'attribue correctement, l'utilisateur doit avoir des coordonnées enregistrées. Si vous sautez cette étape lors du provisioning, l'utilisateur y sera invité à sa première connexion, et tant qu'elles n'existent pas, l'attribution de l'entitlement peut se bloquer. Renseignez-les dans le cadre de votre flux de configuration afin que rien en aval n'ait à attendre.

Étape 3 : confirmez que la signature s'est réellement synchronisée

Voici la subtilité. La vérification de l'entitlement ne lit pas le moment où l'utilisateur a cliqué sur “accepter”, elle lit l'enregistrement de compte sauvegardé et synchronisé. Laissez un instant à la signature pour se propager et resynchronisez l'état de l'utilisateur avant de réessayer. Déclencher addEntitlementSubscription à la même milliseconde où l'utilisateur accepte est un moyen sûr de retomber sur la même erreur à cause d'une condition de course. Confirmez d'abord que l'accord apparaît comme signé dans les données synchronisées.

Étape 4 : appelez addEntitlementSubscription

Une fois l'accord signé et synchronisé et les coordonnées en place, attribuez l'entitlement. L'appel dispose désormais d'un compte valide et éligible auquel s'accrocher, et il répond proprement. Revérifiez le corps de la réponse, un succès ne contiendra pas de errorText. Si vous provisionnez par lots, ne marquez un utilisateur comme “terminé” qu'après avoir vérifié le corps, pas le code de statut.

Étape 5 : vérifiez que l'utilisateur dispose désormais de données en direct

Bouclez la boucle en confirmant que l'utilisateur voit réellement des cotations en temps réel. Faites-lui ouvrir un symbole du mois le plus proche et vérifiez qu'il est en direct plutôt que retardé. Si l'entitlement a été attribué mais que l'utilisateur voit toujours des données retardées, il faudra peut-être aussi se pencher sur le côté abonnement aux données de marché, l'entitlement et un abonnement de données actif sont liés mais pas identiques, et les deux doivent être corrects pour un flux en direct propre.

L'ordre de provisioning qui fonctionne

Presque tous les tickets “Live account is required” s'expliquent par des appels exécutés dans le mauvais ordre ou par une étape sautée. Respectez la séquence :

Tableau de dépannage

Une remarque sur les comptes prop et d'évaluation

Les comptes d'évaluation et simulés acheminent tout de même des données de marché en direct, donc l'exigence de l'accord ne disparaît pas simplement parce qu'aucun argent réel n'est en jeu. Ce qui change, c'est la propriété. De nombreuses firmes prop gèrent les données de marché et les entitlements de façon centralisée dans le cadre du compte qu'elles vous délivrent, dans ces cas-là, vous ne devriez pas appeler addEntitlementSubscription du tout, et le faire peut entrer en conflit avec la manière dont la firme provisionne les données. Les règles varient selon la firme et le type de compte, confirmez donc le processus actuel de votre firme avant de provisionner vous-même des entitlements. Lorsque la firme est propriétaire du pipeline de données, la solution en cas de données en direct manquantes est une demande de support auprès d'elle, pas un appel API de votre part.

Évitez toute la gymnastique des entitlements avec PickMyTrade

Si votre objectif est simplement de trader vos signaux TradingView sur un compte Tradovate en direct, et non de gérer un pipeline de provisioning, PickMyTrade s'occupe de la tuyauterie côté courtier afin que vous n'ayez jamais à toucher aux appels d'entitlement :

• Connexion gérée, l'état de l'accord de données et de l'entitlement de votre compte est respecté avant même l'envoi d'un ordre, vous n'avez donc pas à déboguer un errorText dans une réponse API brute.
• Routage alerte-vers-ordre, les alertes TradingView circulent directement vers votre compte Tradovate sans que vous ayez à écrire ou séquencer des appels API.
• Conscience de l'entitlement et du risque, les ordres respectent l'état des données de votre compte et les limites de la firme prop au lieu de rebondir sur un prérequis manquant.
• Synchronisation multi-comptes, répliquez un signal sur plusieurs comptes sans avoir à résoudre le provisioning pour chacun d'eux.