Trouvez la première étape manquante : l’événement d’alerte TradingView, la livraison du webhook, l’enregistrement du service récepteur ou la réponse d’ordre de Rithmic. Une alerte déclenchée ne prouve pas une exécution. Conservez les horodatages et les journaux avant de modifier des paramètres ou de renvoyer quoi que ce soit. TradingView documente des nouvelles tentatives pour certaines erreurs serveur HTTP ; ne supposez donc pas qu’un déclenchement ne peut produire qu’une seule livraison.
Conseils éducatifs sur le logiciel. Le trading comporte des risques. Lire les avertissements financiers et d'information.
Partir des preuves dont vous disposez
| Dernière étape confirmée | Prochaine vérification utile |
|---|---|
| Signal de stratégie/d’indicateur sur le graphique | Une alerte active a-t-elle été créée pour l’événement prévu ? |
| Alerte dans le Log de TradingView | Configuration de l’URL du webhook et Webhook status |
| Résultat de la livraison HTTP | Enregistrement du service récepteur et validation de la charge utile |
| Le service a accepté l’alerte | Connexion/compte prévu et demande d’ordre enregistrée |
| Le courtier a accusé réception d’une demande | État réel : en attente, rejeté, annulé ou exécuté |
Si le résultat d’un ordre est incertain, vérifiez le compte et l’enregistrement des ordres avant de renvoyer l’alerte. Un délai d’attente dépassé peut laisser inconnu le résultat du traitement chez le destinataire.
1. Confirmer l’alerte active
Vérifiez son état d’activation, sa condition, son symbole, son unité de temps et son expiration. Pour les alertes de script, TradingView utilise un contexte enregistré de script, d’entrées et de graphique. Modifier le graphique ou les entrées du script ne met pas à jour cet instantané existant ; recréez l’alerte lorsque ce contexte doit changer, en suivant la documentation des alertes de TradingView.
Faites correspondre l’événement à l’intégration : une condition d’indicateur, un appel à alert() et un événement d’exécution d’ordre d’une stratégie sont des sources différentes. Sélectionner les deux flux d’événements ne peut envoyer deux requêtes que si les deux se déclenchent réellement et contiennent des messages de trading. Examinez la chronologie plutôt que de supposer un doublon.
2. Examiner la livraison du webhook
Le guide officiel de configuration des webhooks documente le champ de notification, l’exigence d’authentification à deux facteurs et la colonne Webhook status. Utilisez le point de terminaison exact copié depuis l’application réceptrice. Ne devinez pas le chemin d’une URL PickMyTrade.
| Famille de résultat | À examiner |
|---|---|
| Redirection | Point de terminaison modifié ou redirection d’autorisation |
| Erreur client | Accès, point de terminaison, format ou limite de requêtes |
| Erreur serveur | Défaillance du service récepteur et renvoi possible |
| Délai dépassé/URL indisponible | Temps de réponse, accessibilité publique et exactitude du point de terminaison |
Ce sont des catégories de diagnostic issues du guide des erreurs de TradingView, et non des messages d’erreur PickMyTrade inventés. Une adresse d’aperçu localhost n’est pas un point de terminaison de réception public.
3. Tenir compte des nouvelles tentatives
Le guide de renvoi de TradingView indique que les réponses HTTP 500 à 599, à l’exception de 504, peuvent entraîner des renvois à cinq secondes d’intervalle, avec au maximum quatre envois pour un même déclenchement. N’extrapolez pas cela à tous les délais dépassés ni à toutes les erreurs. Cela n’établit pas comment le service récepteur évite les ordres en double.
4. Vérifier séparément le destinataire et Rithmic
Pour PickMyTrade, utilisez son message actuel généré pour le compte concerné. Comparez le type de signal, la connexion/le compte, le contrat, la quantité et le mode de sortie. Sa référence JSON publiée utilise data et quantity ; les remplacer par des action et qty devinés n’est pas une correction vérifiée. La référence ne remplace ni le générateur actuel ni une charge utile testée.
Conservez toute erreur de validation du service et la réponse du courtier. Confirmez le contrat et le compte résolus avant d’interpréter un « succès ». La cotation native capturée ici montre des données ESZ6, et non un résultat de webhook :
Si l’enregistrement du service est absent malgré une livraison signalée, communiquez par l’intermédiaire du support officiel l’horodatage et le fuseau horaire ainsi que le contexte masqué de la requête. Ne publiez jamais de jetons, de mots de passe ni d’identifiants privés de compte ou d’ordre.
Questions fréquentes
Un succès HTTP signifie-t-il que l’ordre a été exécuté ?
Non. Vérifiez séparément la validation par le service récepteur, l’accusé de réception de l’ordre et l’exécution enregistrée.
TradingView ne fait-il jamais de nouvelle tentative ?
Il documente un renvoi conditionnel pour certaines réponses d’erreur serveur. N’en déduisez ni une nouvelle tentative universelle ni une déduplication côté destinataire.
Dois-je renvoyer une alerte dont le délai a été dépassé ?
Rapprochez d’abord les enregistrements du service récepteur et du courtier. Un second envoi peut produire une autre demande lorsque le résultat précédent est inconnu.
Modifier le graphique corrigera-t-il une alerte de script existante ?
Pas nécessairement. Son contexte enregistré reste distinct ; recréez-la lorsque ce contexte doit changer.