Le déclencheur WhatsApp ne reçoit pas les événements et conflit d'abonnement Webhook (n8n auto-hébergé)

Questions
1

Bonjour à tous,
Je rencontre toujours ce problème et je n’ai pas pu le résoudre.
J’ai effectué des tests supplémentaires :

  • Vérifié les identifiants OAuth.
  • Vérifié HTTPS/SSL.
  • Testé l’URL de test et l’URL de production.
  • Publié le flux de travail.
  • Confirmé que Meta reçoit les événements webhook.
  • Le flux de travail échoue toujours avec :
    « L’ID d’application WhatsApp a déjà un abonnement webhook. »
    Quelqu’un a-t-il expérimenté cela avant ou peut-il suggérer comment supprimer l’abonnement webhook existant ou réinitialiser le déclencheur WhatsApp ?
    Toute aide serait grandement appréciée.
    Merci.

Environnement

  • Version n8n : Dernière version auto-hébergée
  • Déploiement : Docker
  • Fournisseur d’hébergement : Hostinger VPS
  • Système d’exploitation : Ubuntu
  • Domaine : https://n8n-teep.srv1761962.hstgr.cloud
  • HTTPS/SSL : Activé et fonctionnel
  • Intégration WhatsApp : API Cloud WhatsApp Meta (OAuth)
  • Nœud IA : Modèle de chat OpenAI

Description du problème

J’essaie de créer un simple flux de travail de réponse automatique WhatsApp alimenté par l’IA.
Flux de travail :

Déclencheur WhatsApp
      ↓
Agent IA
      ↓
Modèle de chat OpenAI

L’agent IA n’est jamais exécuté car le déclencheur WhatsApp ne reçoit jamais les événements entrants.

Ce qui fonctionne

  • Les identifiants OAuth WhatsApp se connectent correctement.
  • Le test de connexion OAuth est réussi.
  • Le domaine HTTPS est accessible.
  • Le numéro de test de l’API Cloud WhatsApp Meta fonctionne correctement.
  • Je peux envoyer des messages de modèle avec succès depuis le tableau de bord Meta Developer.
  • Le tableau de bord Meta Developer affiche les événements webhook entrants sous Vérifier les webhooks de test.

Ce qui NE fonctionne PAS

Quand je clique sur Exécuter l’étape sur le déclencheur WhatsApp, il entre dans :

Écoute d'un événement de test

J’envoie ensuite un message WhatsApp au numéro de test.
Le déclencheur ne reçoit jamais l’événement et continue d’attendre indéfiniment.
Aucune exécution n’est créée.
L’agent IA ne démarre jamais.

Erreur supplémentaire

Quand je publie ou exécute le flux de travail, je reçois l’erreur suivante :

L'ID d'application WhatsApp a déjà un abonnement webhook.
Supprimez-le ou utilisez une autre application avant d'exécuter le déclencheur.
En raison des limitations de l'API WhatsApp, vous ne pouvez avoir qu'un seul déclencheur par application.

Ce que j’ai déjà essayé

  • Recréé les identifiants OAuth WhatsApp.
  • Vérifié que les identifiants OAuth sont valides.
  • Testé l’URL de test et l’URL de production.
  • Publié le flux de travail.
  • Vérifié le certificat SSL.
  • Confirmé que Meta reçoit les événements webhook.
  • Reconstruit le flux de travail à partir de zéro.
  • Testé avec seulement un nœud de déclencheur WhatsApp.
  • Supprimé l’agent IA du test.
  • Vérifié que le problème n’est pas lié au nœud OpenAI.

Informations supplémentaires

J’ai une autre instance n8n auto-hébergée en cours d’exécution sur un autre VPS Hostinger.
Il est possible que la même application Meta WhatsApp ait été précédemment connectée à cette instance.
Je ne suis pas certain qu’un ancien abonnement webhook empêche cette nouvelle instance d’enregistrer son webhook.

Questions

  1. Comment puis-je identifier quel webhook est actuellement enregistré pour mon application WhatsApp ?
  2. Y a-t-il un moyen de supprimer ou de remplacer l’abonnement webhook existant sans créer une nouvelle application Meta ?
  3. Le déclencheur WhatsApp désenregistre-t-il automatiquement les anciens webhooks ?
  4. Y a-t-il une commande ou un point de terminaison API que je peux utiliser pour réinitialiser manuellement l’enregistrement du webhook ?
  5. Y a-t-il des journaux que je dois vérifier sur mon instance n8n auto-hébergée pour diagnostiquer pourquoi l’enregistrement du webhook échoue ?

Comportement attendu

Les messages WhatsApp entrants doivent déclencher immédiatement le flux de travail.

Comportement réel

Le déclencheur reste en « Écoute d’un événement de test » indéfiniment, et la publication du flux de travail produit une erreur de conflit d’abonnement webhook.
Toute aide serait grandement appréciée.
Merci.
Voici les détails complets :

2

@Hussain_Farooq cette erreur exacte, n8n vérifie les abonnements webhook existants de ton app et abandonne quand son callback_url ne correspond pas à l’URL que ce trigger veut, et meta n’autorise qu’un seul webhook par app. donc meta livre tes événements à cet autre/ancien callback url, c’est pour ça que le dashboard affiche des événements mais le trigger ne les voit jamais. correction : dans le dashboard de ton app meta va à WhatsApp > Configuration et supprime le callback webhook existant (ou définis-le sur l’URL exacte affichée sur le nœud trigger n8n), puis active le workflow pour que n8n enregistre son URL de production et assure-toi que le champ messages est abonné. c’est un trigger par app, donc si un autre flow ou une autre instance a déjà enregistré un callback là c’est ton conflit.

3

Pour voir exactement ce qui est enregistré, vous devez utiliser l’explorateur API Meta Graph ou curl. L’abonnement se fait au niveau du compte professionnel WhatsApp (WABA), pas seulement au niveau de l’application.

La vérification : Exécutez une requête GET sur le point de terminaison suivant : https://graph.facebook.com/v21.0/{your-waba-id}/subscribed_apps (Remplacez {your-waba-id} par votre ID de compte professionnel WhatsApp trouvé dans les paramètres Meta Business).

Si la réponse contient votre ID d’application, cette application est actuellement abonnée pour recevoir les événements de ce compte, ce qui explique pourquoi n8n est bloqué.

Pour « dégager la voie » pour votre nouvelle instance n8n, vous devez désabonner l’application du WABA.

La correction via l’API Graph :

  1. Allez à l’explorateur API Meta Graph.
  2. Sélectionnez votre application et assurez-vous que vous disposez d’un jeton utilisateur système ou d’un jeton d’accès à la page avec les permissions whatsapp_business_management.
  3. Changez la méthode en DELETE.
  4. Entrez le point de terminaison : /{your-waba-id}/subscribed_apps
  5. Exécutez la requête. Cela supprime l’abonnement de l’application au WABA et libère le « verrou ».

Non, pas de manière fiable sur différentes instances. Bien que le nœud essaie de mettre à jour le webhook lorsque vous activez un flux de travail sur la même instance, il ne peut pas connaître les abonnements créés par un serveur/VPS différent. Lorsque vous avez migré vers le nouveau VPS Hostinger, l’API Meta se souvenait toujours de l’URL de rappel de l’ancien VPS.

Si vous préférez utiliser le terminal, vous pouvez utiliser ces commandes curl (remplacez les espaces réservés) :

Pour vérifier l’abonnement actuel :

curl -X GET "https://graph.facebook.com/v21.0/<WABA_ID>/subscribed_apps?access_token=<YOUR_TOKEN>"

Pour supprimer l’abonnement :

curl -X DELETE "https://graph.facebook.com/v21.0/<WABA_ID>/subscribed_apps?access_token=<YOUR_TOKEN>"

Si l’erreur persiste après le nettoyage de l’API, vérifiez vos journaux Docker pour voir la réponse d’erreur brute exacte de Meta :

docker logs -f <your-n8n-container-name>

Recherchez les entrées contenant whatsapp ou webhook registration. Si vous voyez une 400 Bad Request avec un code d’erreur spécifique de Meta, cela confirmera si le problème est un « abonnement en double » ou une « échec de validation » (qui se produit si votre variable d’environnement WEBHOOK_URL est incorrecte).

Si vous voulez que cela fonctionne immédiatement, suivez cette séquence exacte :

  1. Nettoyer Meta : Exécutez la requête DELETE sur /{waba-id}/subscribed_apps comme décrit ci-dessus.
  2. Effacer l’état interne de n8n :
    • Ouvrez votre flux de travail.
    • Supprimez entièrement le nœud de déclencheur WhatsApp.
    • Enregistrez le flux de travail.
    • Actualisez la page du navigateur.
    • Ajoutez à nouveau le nœud de déclencheur WhatsApp à partir de zéro. (Cela force n8n à oublier les ID d’enregistrement mis en cache).
  3. Vérifier les variables d’environnement : Assurez-vous que votre variable d’environnement Docker WEBHOOK_URL est exactement https://n8n-teep.srv1761962.hstgr.cloud.
  4. Publier : « Publiez » le flux de travail d’abord, au lieu de cliquer sur « Exécuter l’étape ». L’activation du flux de travail est le moyen le plus fiable pour n8n d’enregistrer l’URL de production.