Comment vérifier la livraison d’une notification et la renvoyer

Si un événement apparaît déjà dans Cryptanio, mais que le message n’est pas arrivé, ouvrez « Livraisons » : vous y trouverez le canal, les tentatives et le résultat de l’envoi. Une livraison terminée peut être renvoyée. Cela crée une nouvelle entrée de livraison pour le même événement ; l’original reste dans l’historique. Aucun nouveau transfert ni événement de blockchain n’est créé.

Prenons le cas d’un serveur de boutique qui a temporairement cessé d’accepter les webhooks, puis a redémarré normalement. Il faut retrouver l’envoi en échec et transmettre à nouveau la notification. Les mêmes vérifications conviennent à une messagerie, même si un envoi réussi ne prouve pas que quelqu’un a lu le message.

Ce qu’il vous faut

Vous devez avoir accès au bon compte et au bon projet. Un membre disposant d’un accès en lecture peut consulter l’historique ; le renvoi exige le droit de modifier les données. Préparez l’heure de l’événement, le projet et le canal. Pour un webhook, l’identifiant event_id du journal de votre application est utile. Il s’agit de l’identifiant de l’événement, pas du TXID du transfert.

Si le canal n’est pas encore connecté, suivez d’abord le guide correspondant : Telegram, Discord ou Slack. Ici, nous vérifions une livraison déjà configurée.

1. Retrouvez d’abord l’événement

Ouvrez « Événements » et vérifiez que le transfert recherché est enregistré dans le projet attendu. Comparez le réseau, l’adresse, l’actif, le sens et l’identifiant de transaction. Un transfert entrant détecté et un transfert entrant confirmé sont des états distincts qui peuvent avoir des notifications séparées.

Si l’événement est absent, renvoyer une livraison ne le récupérera pas depuis la blockchain. Vérifiez les règles et l’activité du suivi, l’état du service et le projet choisi. Le guide sur plusieurs portefeuilles explique comment rattacher les adresses.

2. Retrouvez l’entrée dans Livraisons

Ouvrez « Livraisons ». Choisissez le canal dans « Chaîne » et le « Projet », puis définissez si nécessaire la date de début dans « À partir du jour ». Si vous connaissez le event_id exact, saisissez-le dans « ID d'événement ». Cliquez sur « Appliquer des filtres ». Dans une vue propre à un projet, le périmètre du projet est déjà défini.

Vérifiez l’état de l’entrée : « En vol » indique un envoi en cours, « Échec » un échec et « Livré » une livraison réussie. Cliquez sur le bouton d’ouverture « Ouvert » pour afficher « Détails de livraison » : nombre de tentatives, « Dernière réponse », heure de mise en file d’attente et heure de fin. En cas d’erreur, sa description est disponible. Un même identifiant d’événement peut avoir plusieurs livraisons dans différents canaux.

L’absence de code HTTP ne prouve pas à elle seule un échec : le résultat dépend du canal. Pour un webhook, rapprochez la réponse de votre journal serveur. Le champ de destination peut être protégé et ne pas afficher l’adresse complète contenant un secret.

3. Corrigez la cause avant le renvoi

Vérifiez la disponibilité du gestionnaire, les autorisations de l’application ou l’accès au canal concerné. Pour une messagerie, contrôlez les pauses de la connexion et de la route ; si l’autorisation est révoquée, utilisez « Reconnecter » lorsque ce bouton est disponible. Le test de connexion envoie un message de service distinct, sans rejouer le paiement choisi.

Pour un webhook, assurez-vous que le gestionnaire vérifie la signature et enregistre correctement les événements acceptés. Consultez le guide de confirmation automatique des commandes. Le renvoi ne corrige pas une erreur dans le code du destinataire.

4. Mettez une nouvelle livraison en file d’attente

Sur une entrée terminée, cliquez sur « Renvoyer ». Dans la boîte de dialogue « Renvoyer la notification ? », confirmez avec « Mettre une autre livraison en file d'attente ». Le renvoi est indisponible tant que l’entrée est « En vol », c’est-à-dire en cours : attendez la livraison actuelle au lieu de créer des envois concurrents.

Cryptanio crée un nouvel identifiant de livraison en conservant l’identifiant de l’événement et son contenu enregistré. L’entrée d’origine et son résultat ne sont pas réécrits. Une livraison déjà réussie peut aussi être répétée : cette action peut donc créer un doublon chez le destinataire. Les emails à usage unique contenant des liens d’accès ne peuvent pas être renvoyés de cette manière.

Il s’agit de répéter une ancienne notification, pas d’obtenir le dernier état de la facture ni de transférer automatiquement le message vers un autre canal. Modifier une route ne reconstruit pas le contenu d’un ancien événement.

5. Vérifiez la nouvelle entrée

Actualisez la liste et retrouvez la nouvelle livraison du même événement. Attendez le résultat : une mise en file d’attente ne signifie pas encore une réussite. Si l’envoi échoue à nouveau, lisez la nouvelle cause et vérifiez le destinataire plutôt que de cliquer plusieurs fois sur la même action.

Le gestionnaire de la boutique doit enregistrer event_id et éviter de fournir le produit deux fois. Même après une livraison réussie, l’exécution de la commande exige l’état actuel de la facture. « Livré » confirme le résultat d’envoi de la notification, pas le paiement de la commande, sa lecture par une personne ou l’exécution des actions de votre application.