La campagne est partie. Reste la question à laquelle personne ne sait répondre sans exporter quelque chose : qui a reçu ? Le statut de chaque envoi existe, mais il vit dans le portail du fournisseur. Le webhook de retour le ramène dans la fiche du client, là où il sert à la décision suivante.
Comment fonctionne le webhook
Quand le statut d’un message change, le fournisseur fait un appel HTTP vers une URL que vous avez indiquée. Le corps de l’appel contient l’événement : l’identifiant du message, le nouveau statut et d’autres données qui varient d’un fournisseur à l’autre.
De votre côté, quelqu’un doit recevoir cet appel, répondre vite et écrire le statut. Répondre vite compte : si la réponse tarde, le fournisseur considère que l’appel a échoué et réessaie.
Dans DeepMiner, la réception se contente de vérifier l’URL et de placer l’événement dans une file, puis répond aussitôt. Le traitement a lieu juste après, en dehors de l’appel du fournisseur.
Trouver le bon enregistrement
L’événement indique quel message a changé de statut. Il vous faut savoir quel client a reçu ce message. Il existe deux façons courantes de faire ce lien.
La première consiste à envoyer une référence de l’enregistrement avec le message, que le fournisseur renvoie dans l’événement. La seconde consiste à garder l’identifiant renvoyé par le fournisseur à l’envoi et à le chercher à l’arrivée de l’événement.
DeepMiner utilise les deux. Il cherche d’abord la référence de l’enregistrement et, à défaut, l’identifiant du message enregistré à l’envoi. La recherche reste limitée aux index du partenaire liés à ce fournisseur. Quand rien ne correspond, l’événement est consigné comme sans correspondance.
Ce qu’il faut écrire dans l’enregistrement
Le statut seul aide déjà, mais l’enregistrement devient plus utile avec un peu de contexte. Pour chaque canal, DeepMiner écrit le statut, la date de la dernière mise à jour et les champs d’événement définis pour ce type de fournisseur. L’événement complet entre dans l’historique de l’enregistrement, qui garde les derniers événements de tous les fournisseurs.
Comme chaque canal écrit ses propres champs, un même client peut avoir le statut du SMS et celui du RCS côte à côte, visibles dans la liste des enregistrements de l’index.
Doublons et sécurité de l’URL
Les événements répétés arrivent, et écrire deux fois brouille l’historique. DeepMiner identifie le corps de chaque événement déjà appliqué et marque la répétition comme doublon. La marque n’est écrite qu’une fois la mise à jour réussie : un échec en cours de route laisse donc l’événement s’appliquer à la tentative suivante.
L’URL est l’identifiant du webhook. Qui la connaît peut envoyer des événements. C’est pourquoi, dans DeepMiner, chaque fournisseur a sa propre URL avec un token aléatoire, affiché une seule fois. Seule une signature du token est conservée. Si l’URL fuite, Régénérer le token en crée une nouvelle et l’ancienne cesse de fonctionner. Avant d’appliquer un événement, DeepMiner revérifie que le fournisseur est toujours actif et que le token est toujours le même.
Le journal de chaque événement
Quand un statut n’apparaît pas, la première question est de savoir si l’événement est arrivé. Le journal des webhooks répond : chaque événement s’y affiche comme traité, doublon, sans correspondance ou en échec, avec le payload pour vérification. Le détail de l’enregistrement montre les événements des fournisseurs pour ce client.
Ce qui change ensuite
Avec le retour dans l’enregistrement, le suivi de la campagne se fait à trois endroits. L’exécution affiche le total d’enregistrements, les envois et les échecs. La liste des enregistrements de l’index montre le statut de chaque canal par client, et le détail de l’enregistrement garde les événements. Le journal des webhooks montre ce qui est arrivé du fournisseur et ce qui n’a pas trouvé d’enregistrement.
Vous voulez voir un événement de retour arriver dans l’enregistrement ? Planifiez une démonstration.
Questions fréquentes
Qu’est-ce qu’un webhook de retour ?
C’est une URL que le fournisseur de messages appelle pour signaler que le statut d’un envoi a changé. Le système qui la reçoit écrit ce statut là où il est utile.
Pourquoi le même événement arrive-t-il deux fois ?
Les fournisseurs renvoient souvent l’événement quand ils ne reçoivent pas d’accusé de réception à temps. Celui qui reçoit doit reconnaître l’événement répété et ne pas appliquer deux fois la même mise à jour.
Comment DeepMiner sait-il à quel enregistrement l’événement appartient ?
Par la référence de l’enregistrement envoyée avec le message ou par l’identifiant du message que le fournisseur a renvoyé à l’envoi. Seuls les index liés à ce fournisseur sont pris en compte.