WhatsApp Trigger No Recibe Eventos y Conflicto de Suscripción Webhook (n8n Auto-hospedado)

Hola a todos,
Sigo experimentando este problema y no he podido resolverlo.
He realizado pruebas adicionales:

  • Verifiqué las credenciales de OAuth.
  • Verifiqué HTTPS/SSL.
  • Probé tanto la URL de Prueba como la URL de Producción.
  • Publiqué el flujo de trabajo.
  • Confirmé que Meta recibe eventos de webhook.
  • El flujo de trabajo sigue fallando con:
    “La App ID de WhatsApp ya tiene una suscripción de webhook.”
    ¿Alguien ha experimentado esto antes o puede sugerir cómo eliminar la suscripción de webhook existente o reiniciar el Disparador de WhatsApp?
    Cualquier ayuda sería muy apreciada.
    Gracias.

Entorno

  • Versión de n8n: Última versión auto-alojada
  • Implementación: Docker
  • Proveedor de hospedaje: Hostinger VPS
  • Sistema operativo: Ubuntu
  • Dominio: https://n8n-teep.srv1761962.hstgr.cloud
  • HTTPS/SSL: Habilitado y funcionando
  • Integración de WhatsApp: API de WhatsApp Cloud de Meta (OAuth)
  • Nodo de IA: Modelo de Chat de OpenAI

Descripción del problema

Estoy intentando crear un flujo de trabajo simple de respuesta automática con IA para WhatsApp.
Flujo de trabajo:

Disparador de WhatsApp
      ↓
Agente de IA
      ↓
Modelo de Chat de OpenAI

El Agente de IA nunca se ejecuta porque el Disparador de WhatsApp nunca recibe eventos entrantes.

Qué funciona

  • Las credenciales de OAuth de WhatsApp se conectan correctamente.
  • La prueba de conexión de OAuth es exitosa.
  • El dominio HTTPS es accesible.
  • El número de prueba de la API de WhatsApp Cloud de Meta funciona correctamente.
  • Puedo enviar mensajes de plantilla exitosamente desde el Panel de Desarrollador de Meta.
  • El Panel de Desarrollador de Meta muestra eventos de webhook entrantes en Verificar webhooks de prueba.

Qué NO funciona

Cuando hago clic en Ejecutar paso en el Disparador de WhatsApp, entra en:

Escuchando evento de prueba

Luego envío un mensaje de WhatsApp al número de prueba.
El disparador nunca recibe el evento y sigue esperando indefinidamente.
No se crea ninguna ejecución.
El Agente de IA nunca se inicia.

Error adicional

Cuando publico o ejecuto el flujo de trabajo, recibo el siguiente error:

La App ID de WhatsApp ya tiene una suscripción de webhook.
Elímina o usa otra App antes de ejecutar el disparador.
Dado a las limitaciones de la API de WhatsApp, solo puedes tener un disparador por App.

Lo que ya he intentado

  • Recreé las credenciales de OAuth de WhatsApp.
  • Verifiqué que las credenciales de OAuth sean válidas.
  • Probé tanto la URL de Prueba como la URL de Producción.
  • Publiqué el flujo de trabajo.
  • Verifiqué el certificado SSL.
  • Confirmé que Meta recibe eventos de webhook.
  • Reconstruí el flujo de trabajo desde cero.
  • Probé solo con un nodo Disparador de WhatsApp.
  • Eliminé el Agente de IA de las pruebas.
  • Verifiqué que el problema no esté relacionado con el nodo de OpenAI.

Información adicional

Tengo otra instancia de n8n auto-alojada ejecutándose en otro VPS de Hostinger.
Es posible que la misma App de WhatsApp de Meta haya sido conectada previamente a esa instancia.
No estoy seguro si una suscripción de webhook anterior está impidiendo que esta nueva instancia registre su webhook.

Preguntas

  1. ¿Cómo puedo identificar qué webhook está registrado actualmente para mi App de WhatsApp?
  2. ¿Hay una forma de eliminar o reemplazar la suscripción de webhook existente sin crear una nueva App de Meta?
  3. ¿El Disparador de WhatsApp anula automáticamente los webhooks antiguos?
  4. ¿Hay algún comando o punto final de API que pueda usar para reiniciar manualmente el registro del webhook?
  5. ¿Hay registros que deba verificar en mi instancia auto-alojada de n8n para diagnosticar por qué falla el registro del webhook?

Comportamiento esperado

Los mensajes de WhatsApp entrantes deberían activar el flujo de trabajo inmediatamente.

Comportamiento actual

El disparador permanece en “Escuchando evento de prueba” indefinidamente, y publicar el flujo de trabajo produce un error de conflicto de suscripción de webhook.
Cualquier orientación sería muy apreciada.
Gracias.
Aquí están los detalles completos:

@Hussain_Farooq ese error exacto, n8ns trigger checks comprueba la suscripción de webhook existente de tu aplicación y falla cuando su callback_url no coincide con la url que este trigger quiere, y meta solo permite un webhook por aplicación. entonces meta está entregando tus eventos a ese otro/anterior callback url, por eso el dashboard muestra eventos pero el trigger nunca los ve. solución: en el dashboard de tu aplicación meta ve a WhatsApp > Configuration y elimina el callback de webhook existente (o establécelo en la url exacta mostrada en el nodo trigger de n8n), luego activa el workflow para que n8n registre su url de producción y asegúrate de que el campo messages esté suscrito. es un trigger por aplicación, así que si otro flow o instancia ya registró un callback allí ese es tu conflicto.

Para ver exactamente qué está registrado, debes usar el Meta Graph API Explorer o curl. La suscripción ocurre a nivel de Cuenta Comercial de WhatsApp (WABA), no solo a nivel de aplicación.

La verificación: Ejecuta una solicitud GET al siguiente endpoint: https://graph.facebook.com/v21.0/{your-waba-id}/subscribed_apps (Reemplaza {your-waba-id} con tu ID de Cuenta Comercial de WhatsApp que se encuentra en la Configuración Comercial de Meta).

Si la respuesta contiene tu ID de aplicación, esa aplicación está actualmente suscrita para recibir eventos de esa cuenta, por lo que n8n está bloqueado.

Para «despejar el camino» de tu nueva instancia de n8n, necesitas desuscribir la aplicación de la WABA.

La solución mediante Graph API:

  1. Ve al Meta Graph API Explorer.
  2. Selecciona tu aplicación y asegúrate de tener un Token de Usuario del Sistema o un Token de Acceso de Página con permisos de whatsapp_business_management.
  3. Cambia el método a DELETE.
  4. Ingresa el endpoint: /{your-waba-id}/subscribed_apps
  5. Ejecuta la solicitud. Esto elimina la suscripción de la aplicación a la WABA y libera el «bloqueo».

No, no de manera confiable entre diferentes instancias. Aunque el nodo intenta actualizar el webhook cuando activas un flujo en la misma instancia, no puede saber sobre las suscripciones creadas por un servidor/VPS diferente. Cuando te trasladaste al nuevo VPS de Hostinger, la API de Meta aún recordaba la URL de callback del VPS anterior.

Si prefieres usar la terminal, puedes usar estos comandos de curl (reemplaza los marcadores de posición):

Para verificar la suscripción actual:

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

Para eliminar la suscripción:

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

Si el error persiste después de la limpieza de la API, verifica tus registros de Docker para ver la respuesta de error sin procesar exacta de Meta:

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

Busca entradas que contengan whatsapp o webhook registration. Si ves un 400 Bad Request con un código de error específico de Meta, confirmará si el problema es una «suscripción duplicada» o una «falla de validación» (que ocurre si tu variable de entorno WEBHOOK_URL es incorrecta).

Si quieres que esto funcione inmediatamente, sigue esta secuencia exacta:

  1. Limpiar Meta: Ejecuta la solicitud DELETE en /{waba-id}/subscribed_apps como se describe arriba.
  2. Borrar el estado interno de n8n:
    • Abre tu flujo.
    • Elimina completamente el nodo Disparador de WhatsApp.
    • Guarda el flujo.
    • Actualiza la página del navegador.
    • Vuelve a agregar el nodo Disparador de WhatsApp desde cero. (Esto obliga a n8n a olvidar cualquier ID de registro en caché).
  3. Verifica las variables de entorno: Asegúrate de que tu variable de entorno de Docker WEBHOOK_URL sea exactamente https://n8n-teep.srv1761962.hstgr.cloud.
  4. Publicar: «Publica» el flujo primero, en lugar de hacer clic en «Ejecutar paso». Activar el flujo es la forma más confiable para que n8n registre la URL de producción.