Webhooks WhatsApp : acheminer les messages directement vers votre serveur
Un webhook WhatsApp est un endpoint HTTPS que vous désignez et auquel Meta envoie des événements : messages entrants, statuts de livraison, changements de qualité et mises à jour du compte. Sur un numéro Coexistence, la destination peut être votre propre serveur : les conversations ne passent alors jamais par un fournisseur.
- Meta envoie les événements directement vers votre URL
- Votre endpoint, pas la plateforme d'un fournisseur
- Un seul remplacement par WhatsApp Business Account
Aucun frais pendant 7 jours. Annulez à tout moment.
Ce que couvre toute l'intégration : une destination HTTPS par compte.
messages et smb_message_echoes, les événements du parcours des messages qui vous sont acheminés.
La valeur envoyée par Meta lors de sa vérification GET, que votre endpoint doit renvoyer.
Qu'envoie réellement Meta à un webhook ?
Des événements, répartis en catégories, et la distinction entre eux détermine votre architecture.
Le parcours des messages contient ce que les clients envoient et, sur un numéro Coexistence, les échos de ce que votre équipe envoie depuis l'application WhatsApp Business. Il s'agit des champs messages et smb_message_echoes, les seuls qui contiennent le contenu des conversations.
Le parcours opérationnel contient tout le reste : account_update lorsqu'un état de connexion change, phone_number_quality_update lorsque la qualité ou le débit évolue, account_alerts, account_review_update, business_capability_update et phone_number_name_update. Ces événements ne contiennent aucun contenu de conversation et servent de base à la supervision.
Un fournisseur placé sur le parcours des messages reçoit le premier groupe. Un fournisseur qui ne s'y trouve pas ne le reçoit pas.
Comment Meta vérifie-t-elle un endpoint ?
Avec une requête GET avant toute livraison. C'est la raison la plus fréquente pour laquelle une configuration apparemment terminée ne reçoit jamais de message.
Meta appelle votre URL avec hub.mode défini sur subscribe, votre hub.verify_token et une valeur hub.challenge. Votre endpoint doit renvoyer cette valeur challenge comme corps de réponse brut, sans JSON ni ajout. Sinon, Meta ne commence jamais les livraisons et aucun dashboard ne l'indique.
L'endpoint doit également être en HTTPS. Un endpoint qui renvoie une 404 silencieuse, ou qui se trouve derrière une couche d'authentification rejetant Meta, semble fonctionner jusqu'à ce que le premier message n'arrive jamais.
La destination peut-elle pointer vers votre propre serveur ?
Oui, et c'est ce qui différencie les fournisseurs.
Meta permet à une application de remplacer la destination des webhooks d'un WhatsApp Business Account donné. Nous définissons ce remplacement sur votre URL, ce qui achemine les événements du parcours des messages de notre callback vers le vôtre. Nous conservons les événements opérationnels, car ils alimentent le dashboard et les alertes.
La conséquence est architecturale, plutôt qu'une règle que nous publions. Le contenu des conversations ne peut pas être stocké de notre côté, puisqu'il ne nous est jamais livré. Un compte sans remplacement revient à notre callback par défaut, où le gestionnaire ignore ces événements sans les conserver.
Que devient la destination lorsqu'un numéro se reconnecte ?
Elle est supprimée, ce que presque personne ne prévoit.
La destination n'est pas une propriété du numéro de téléphone. Il s'agit d'un remplacement appliqué à l'abonnement de notre application au WhatsApp Business Account. Lorsqu'une connexion est supprimée, en raison de la règle d'inactivité de quatorze jours de Meta ou pour toute autre raison, l'application est désinstallée de ce compte et le remplacement disparaît avec elle.
La reconnexion rétablit l'envoi et la supervision. Elle ne rétablit pas la livraison vers votre serveur et aucune erreur n'est signalée. Le premier signe est donc souvent un client qui indique que personne ne lui a répondu. Nous réappliquons le remplacement à chaque reconnexion, car cela est arrivé à un vrai numéro qui s'est reconnecté correctement avant de devenir silencieux.
Erreurs courantes
- Renvoyer du JSON lors de la vérification GET. Meta attend la valeur brute de hub.challenge, et rien d'autre.
- Utiliser une URL temporaire ou de test. Meta continue de lui envoyer des requêtes après l'arrêt de l'outil qui l'a générée.
- Supposer que la destination reste après une reconnexion. Elle dépend d'un abonnement d'application et est désinstallée avec lui.
- Placer l'endpoint derrière une authentification qui rejette la requête de Meta.
EasyCoexistence définit le remplacement du webhook sur votre endpoint, le valide avant l'appel et le réapplique automatiquement après chaque reconnexion. À partir de US$ 9 par numéro et par mois, jusqu'à US$ 2 selon le volume, avec les 7 premiers jours gratuits.
Questions fréquemment posées
Mes messages passent-ils par EasyCoexistence ?
Non. Le remplacement envoie les événements du parcours des messages directement de Meta vers votre endpoint. Les événements d'un compte sans remplacement reviennent à notre callback et sont ignorés sans être conservés.
Puis-je modifier la destination plus tard ?
Oui, à tout moment, depuis le dashboard ou via le connecteur MCP. En transmettant null, vous revenez à notre destination par défaut.
Que se passe-t-il si mon serveur est indisponible lorsque Meta livre les messages ?
Meta réessaie pendant un certain temps, puis s'arrête. Les messages arrivent toujours dans l'application WhatsApp Business du téléphone : l'entreprise ne perd donc rien, même lorsque l'intégration échoue.
Un seul webhook suffit-il pour plusieurs numéros ?
Oui. Pointez chaque numéro vers le même endpoint et utilisez l'identifiant du numéro de téléphone destinataire dans le payload pour les distinguer.
Poursuivre la lecture
Prêt à commencer ?
Configurez WhatsApp Coexistence en quelques minutes, pas en quelques mois. L’application continue de fonctionner sur le téléphone.
Commencer l'essai gratuitAucun frais pendant 7 jours. Annulez à tout moment.Vérifié le