Le forfait sans frais de Tradovate fait échouer les ordres (404)

Vous faites passer votre compte au forfait sans frais mensuels pour réduire les coûts, et la fois suivante où vous envoyez un ordre, le serveur renvoie 404 Not Found. Rien d'autre ne semble anormal. Vous pouvez vous connecter, votre jeton s'authentifie, votre liste de comptes se charge, les graphiques bougent, mais la seule chose dont vous avez vraiment besoin, envoyer un ordre, échoue avec un corps 404 vide. On dirait que le point de terminaison a disparu au moment où votre forfait a changé.

Ce n'est pas le cas. Un 404 est plus précis qu'il n'y paraît et, une fois que vous savez ce qu'il dit, la solution est courte. Il s'agit presque toujours de l'un de ces deux scénarios : votre ligne de requête pointe vers une route qui n'existe pas (hôte, version, chemin, méthode), ou le droit de routage des ordres de votre compte a été perturbé par le changement de forfait et n'a pas encore été réapprovisionné. Nous écartons d'abord la ligne de requête parce que c'est rapide, puis nous suivons la piste forfait-et-droits, celle qui frappe juste après une rétrogradation.

Ce que vous dit réellement un 404

Chaque statut HTTP renvoie à une couche différente, et les traiter tous pareil vous amène à réparer la mauvaise chose. Un 404 signifie que le serveur n'a pas trouvé ce que désignait votre ligne de requête : la route, ou la cible de routage de votre compte, n'est pas là. Un 401 ou « access is denied » signifie que la route existe mais que vous n'étiez pas autorisé. Un 400 signifie que le chemin et l'authentification étaient corrects mais que le corps était mal formé. Un 429 signifie que vous êtes limité en débit.

Donc, si vous êtes face à un 404 littéral, cessez de modifier le JSON de votre ordre. Le serveur n'est jamais allé assez loin pour le lire. Deux familles de causes produisent un 404 ici : une requête dirigée vers une URL qui n'existe pas, et un compte qui ne peut pas router d'ordres pour le moment parce que son forfait ou son droit n'est pas dans un état autorisant les ordres. Le moment où cela survient est votre meilleur indice. Si les ordres fonctionnaient il y a cinq minutes et que seul votre abonnement a changé, penchez pour l'explication du droit, mais consacrez tout de même soixante secondes à écarter la ligne de requête, car un changement de forfait est aussi un moment naturel pour avoir changé d'environnement ou copié une URL périmée.

D'abord, écartez la ligne de requête

Ce sont les causes banales d'un 404 qui n'ont rien à voir avec votre forfait et se règlent en une minute. Si vous passez des ordres via l'API ou un outil tiers, vérifiez que les quatre éléments de l'URL sont corrects avant de toucher quoi que ce soit côté compte.

• L'hôte correspond à l'environnement. Un compte démo/simulation passe par l'hôte démo ; un compte réel passe par l'hôte réel. Envoyer un ordre réel à l'hôte démo (ou l'inverse) peut renvoyer 404 ou être rejeté comme non autorisé. Si vous venez de changer de forfait sur votre compte réel, assurez-vous que vos outils ne sont pas restés discrètement pointés sur l'hôte de simulation.
• Le segment de version est présent. Le chemin des ordres dépend de la racine versionnée (le segment /v1). Si vous l'omettez, l'hôte nu n'a aucune route d'ordres et vous obtenez 404.
• Orthographe et casse du chemin. Les chemins REST sont sensibles à la casse. Une opération d'ordre avec une casse erronée ou des tirets ne correspond à rien et répond 404.
• La bonne méthode. Le placement d'un ordre est un POST. Coller l'URL dans la barre d'un navigateur (toujours un GET) ou envoyer le mauvais verbe se manifeste par une erreur de type introuvable ou méthode non autorisée.

Si vous passez vos ordres dans l'application de bureau ou web plutôt que par du code, vous ne maîtrisez pas l'URL, donc cette section vous concerne rarement : passez directement à l'histoire du forfait. Si vous utilisez l'API et que la ligne de requête est correcte, ou si sa correction a transformé votre 404 en 401, vous avez dépassé cette couche. Examinez maintenant le compte.

Le vrai déclencheur : le changement de forfait a perturbé le routage des ordres

Voici la partie qui relie le 404 à votre abonnement. Passer des ordres réels ne se résume pas à être connecté. Votre compte doit se trouver sur un forfait actif autorisant les ordres, et porter les droits que ce forfait accorde : le flux de données de marché qui permet à la plateforme de valoriser votre ordre et, pour l'accès programmatique, le droit d'automatisation ou d'API qui autorise le routage depuis du code. Ces droits sont provisionnés sur votre compte ; ils ne sont pas intégrés à votre mot de passe.

Lorsque vous changez de forfait, la plateforme doit démanteler l'ancien ensemble de droits et mettre en place le nouveau. Pendant une brève fenêtre de cet échange, le compte peut se trouver dans un état où la cible de routage d'ordres dont il a besoin n'est pas encore disponible. Une requête qui la sollicite renvoie 404, car du point de vue du serveur il n'y a rien vers quoi router. Votre connexion fonctionne toujours parce que l'authentification vit sur une autre couche. C'est exactement pourquoi le symptôme est si déséquilibré : tout semble normal sauf l'ordre.

Deux variantes reviennent le plus souvent :

• Le nouveau forfait n'a pas fini son approvisionnement. Vous avez choisi le forfait sans frais, le changement a été enregistré, mais les services de données et d'ordres n'ont pas encore suivi. Les ordres renvoient 404 (ou sont rejetés avec « no quote available ») tant que le flux et le routage ne sont pas actifs sur le compte.
• Un module payant n'a pas été reporté. Si votre routage d'ordres dépendait d'un droit payant, un module d'accès à l'API ou d'automatisation s'appuyant sur un forfait payant, la rétrogradation peut le supprimer. Les appels de votre bot qui fonctionnaient hier renvoient désormais 404 parce que le droit qui les autorisait a disparu.

La solution : rétablir un forfait avec routage d'ordres et données activés

L'objectif est de ramener votre compte à une combinaison forfait et modules qui accorde réellement le routage d'ordres réels et les données de marché, puis de forcer le compte à prendre en compte le changement. Procédez dans cet ordre.

Si vous utilisez un compte de prop firm ou d'évaluation

Les règles s'inversent lorsque le compte n'est pas à vous. Sur un compte d'évaluation ou financé d'une prop firm, la firme possède le forfait, l'abonnement aux données et les droits : vous ne pouvez pas changer votre niveau de forfait et vous ne devriez pas essayer. Si les ordres se sont mis à renvoyer 404 sur un compte de firme après un changement de forfait ou de données, c'est à la firme de corriger l'approvisionnement ; contactez-la plutôt que le courtier directement. Les firmes diffèrent aussi sur l'autorisation de l'automatisation directe par API : certaines la permettent, d'autres la bloquent, et les règles exactes ainsi que d'éventuelles limites de compte varient selon la firme et la taille du compte ; vérifiez donc les conditions actuelles de votre firme avant de supposer qu'une correction de code aidera.

Liste de vérification rapide pour éliminer le 404

Arrêtez de surveiller les droits

La plupart des gens qui rencontrent ce problème ne cherchent pas à devenir experts en approvisionnement de comptes. Ils veulent simplement qu'une stratégie entre et sorte de leur compte de futures et continue de fonctionner quand ils changent de forfait. Si c'est votre cas, il existe un chemin plus court que d'écrire à la main des appels d'ordres qui se cassent à chaque changement de droit.

Pour les sujets voisins qui déterminent si les ordres sont routés ou non : comparez les niveaux et ce que chacun accorde dans le comparatif des forfaits Free, Monthly et Lifetime ; assurez-vous que le droit d'automatisation est activé avec le guide sur l'obtention d'un accès API et d'une clé ; et si votre 404 s'est transformé en erreur de permissions, parcourez le guide « Access Is Denied » lors du placement d'un ordre.