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

Aidez-moi à Construire mon Flux de Travail
1

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 WhatsApp Cloud 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 avec succès.
  • Le test de connexion OAuth est réussi.
  • Le domaine HTTPS est accessible.
  • Le numéro de test de l’API WhatsApp Cloud Meta fonctionne correctement.
  • Je peux envoyer avec succès des messages de modèle 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 alors 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éer les identifiants OAuth WhatsApp.
  • Vérifier que les identifiants OAuth sont valides.
  • Tester à la fois l’URL de test et l’URL de production.
  • Publier le flux de travail.
  • Vérifier le certificat SSL.
  • Confirmer que Meta reçoit les événements webhook.
  • Reconstruire le flux de travail à partir de zéro.
  • Tester avec un seul nœud Déclencheur WhatsApp.
  • Supprimer l’Agent IA des tests.
  • Vérifier 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 exécutée sur un autre Hostinger VPS.
Il est possible que la même application Meta WhatsApp ait été précédemment connectée à cette instance.
Je ne suis pas sûr 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. Existe-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 consulter 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 le flux de travail immédiatement.

Comportement réel

Le déclencheur reste dans « É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.

2

Deux choses distinctes doivent être configurées pour que les événements WhatsApp atteignent n8n, et une lacune dans l’une d’elles provoque des pertes silencieuses :

1. Le workflow doit être publié, pas en mode test
Le nœud WhatsApp Trigger possède deux URL de webhook différentes : une URL de test (utilisée quand vous cliquez sur Execute step) et une URL de production (utilisée quand le workflow est publié). Meta ne connaît qu’une seule d’entre elles — celle que vous avez enregistrée. Si vous avez enregistré l’URL de production mais que vous avez ensuite basculé en mode Execute step pour tester, n8n écoute sur la mauvaise URL. Maintenez le workflow publié et surveillez plutôt la liste des Executions.

2. Le conflit de souscription du webhook
Meta autorise une seule URL de webhook par compte WhatsApp Business. Si vous avez précédemment enregistré un webhook sur le même numéro de téléphone ou le même compte professionnel (même à partir d’une autre application ou d’une configuration n8n antérieure), Meta continue d’envoyer vers l’ancienne URL. Pour corriger :

  • Accédez à Meta Developer Console → votre App → WhatsApp → Configuration
  • Sous Webhook, vérifiez que votre URL de webhook de production n8n actuelle est celle indiquée
  • Sous Webhook fields, confirmez que messages est abonné
  • Vérifiez séparément les paramètres du numéro de téléphone : Meta Developer Console → WhatsApp → API Setup → votre ligne de numéro de téléphone → la souscription du webhook peut être remplacée au niveau du numéro de téléphone

Diagnostic rapide : Envoyez un message à votre numéro de test WhatsApp, puis vérifiez immédiatement votre liste d’Executions n8n (pas le canvas). Si vous voyez une exécution déclenchée avec une erreur, le webhook arrive mais échoue en aval. Si la liste des Executions est complètement vide, le webhook n’atteint pas n8n du tout — ce qui indique un problème d’enregistrement côté Meta (URL incorrecte ou souscription obsolète).

3

Salut @Hussain_Farooq, l’indice important est l’erreur subscription-conflict. Je diviserais le diagnostic en trois endroits et prouverais où l’événement s’arrête.

  1. Côté Meta : confirme quelle URL de callback webhook est actuellement enregistrée pour cette App WhatsApp, et si elle pointe toujours vers l’ancien VPS / l’ancienne instance n8n.
  2. Côté n8n : confirme si le workflow actif utilise l’URL de production, pas seulement le test listener. Pour les événements WhatsApp en production, le workflow doit généralement être actif et l’URL webhook de production doit être celle que Meta a.
  3. Côté preuve : envoie un message de test et vérifie s’il y a une exécution dans n8n. Si Meta affiche l’événement mais n8n n’a pas d’exécution, l’événement n’atteint probablement pas cette instance.

Je ne partagerais pas publiquement App Secret, tokens, numéros de téléphone, credentials, ou captures d’écran complètes du dashboard. Une capture d’écran expurgée montrant uniquement le domaine/chemin de l’URL de callback et la liste d’exécution n8n suffit pour un premier passage de triage.