Espacio de trabajo: kmb197806.app.n8n.cloud
ID de flujo: eRzTqWWhGWWQ2eXP
Nodo: Webhook (POST), ruta ghl-whatsapp-leads, webhookId 6bdce384-c129-4223-ab10-238ca40a25db
Problema: Las llamadas de webhook de producción desde un servicio externo (GoHighLevel) no desencadenan ninguna ejecución en n8n, aunque el flujo esté Activo/Publicado y el servicio externo reciba una respuesta de éxito.
Pasos para reproducir:
- El flujo está activo y publicado, nodo webhook configurado con método POST.
- El servicio externo (GHL) llama a la URL de producción: https://kmb197806.app.n8n.cloud/webhook/6bdce384-c129-4223-ab10-238ca40a25db/ghl-whatsapp-leads
- En el lado del servicio que llama, el registro de solicitudes muestra «Finalizado» (lo que implica que se recibió una respuesta de nivel 200).
- En n8n, al verificar Ejecuciones (tanto de este flujo como de toda la cuenta) se muestra no se creó ninguna ejecución nueva para esa llamada.
- Una llamada manual activada en modo producción al mismo webhook (a través de API) se registra y ejecuta correctamente.
Lo que he intentado:
- Recreé el nodo Webhook completamente (nuevo webhookId, misma ruta/método) — pareció ayudar temporalmente, luego el mismo problema volvió a ocurrir.
- Desactivé y volví a publicar el flujo múltiples veces.
- Confirmé que la URL de producción coincida exactamente con lo configurado en el lado del servicio que llama.
Esto parece estar relacionado con otros informes abiertos de problemas de sincronización/registro de webhooks de producción en n8n Cloud (p. ej. #16339, #18387, #23808). Agradecería orientación — esto impide que una automatización de WhatsApp orientada al cliente se lance en producción.
¿Cuál es el mensaje de error (si corresponde)?
Comparte tu flujo
(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo.)
Comparte el resultado devuelto por el último nodo
Información sobre tu configuración de n8n
- Versión de n8n:
- Base de datos (predeterminado: SQLite):
- Configuración n8n EXECUTIONS_PROCESS (predeterminado: own, main):
- Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):
- Sistema operativo:
¡Hola @Maria_Mercedes_Benco! ¡Bienvenida!
El webhookId solo se antepone a la URL cuando el campo Path contiene un segmento dinámico :. ghl-whatsapp-leads es una ruta simple, por lo que la ruta de producción registrada es solo la ruta y el segmento UUID adicional la convierte en una ruta que n8n nunca registró. Responde con 404, y GHL aún lo registra como Finished, ya que ese estado es el paso activándose en lugar del código de respuesta que obtuvo. Ejecuta esto contra la URL que GHL está llamando:
curl -i -X POST https://kmb197806.app.n8n.cloud/webhook/6bdce384-c129-4223-ab10-238ca40a25db/ghl-whatsapp-leads -H "Content-Type: application/json" -d '{"test":true}'
Un cuerpo 404 que nombre al webhook como no registrado lo confirma. Cambia la URL en GHL a:
https://kmb197806.app.n8n.cloud/webhook/ghl-whatsapp-leads
Hola @Maria_Mercedes_Benco
Simplemente cambiar el interruptor “Activo” del flujo de trabajo a menudo no es suficiente porque el registro podría estar en caché.
- Desactiva el flujo de trabajo.
- Cambia la ruta del Webhook ligeramente (por ejemplo, de
ghl-whatsapp-leads a ghl-whatsapp-leads-v2).
- Guarda el flujo de trabajo.
- Activa el flujo de trabajo.
- Actualiza la URL en GoHighLevel a la nueva ruta. Causa raíz: Esto obliga a n8n a crear una entrada de registro completamente nueva en la base de datos e insertarla en la capa de ingreso, omitiendo cualquier caché obsoleto asociado con la ruta/ID anterior.
¿Te ayuda eso?
Hola @Maria_Mercedes_Benco
¿Una llamada manual en modo de producción a la misma URL se ejecuta correctamente?
Hola María,
Anshul tiene tu causa raíz en el post 2 y yo la arreglría primero. Hay una cosa que nadie ha señalado, pero importa más una vez que la URL comience a funcionar.
Tu post contiene el subdominio del espacio de trabajo, el ID del flujo de trabajo y la URL del webhook de producción completa. Los nodos Webhook de n8n no tienen autenticación de forma predeterminada, así que en el momento en que esa ruta se registre correctamente, cualquiera que lea este hilo puede enviar JSON arbitrario a una automatización de WhatsApp orientada al cliente. Ahora mismo el 404 es lo único que la protege.
Dos cosas que vale la pena hacer mientras estés ahí. Establece Autenticación en el nodo Webhook en Header Auth, y elige una nueva ruta en lugar de reutilizar esta. La sugerencia de kjooleng en el post 3 ya hace el segundo trabajo, simplemente tiene este beneficio también.
La cosa más amplia, y la razón por la que esto te costó días en lugar de minutos: «Finished» en GHL describe el propio paso de GHL, no lo que pasó en el otro extremo. Casi todas las integraciones salientes reportan sobre su ejecución en lugar de sobre la recepción, así que un 404, un timeout absorbido por un proxy y una entrega limpia se ven idénticos desde el lado del envío. Cuando un flujo de trabajo es importante, vale la pena que el destino confirme la recepción en lugar de confiar en la ausencia de un error en la fuente. Un curl manual contra la URL exacta que GHL mantiene habría mostrado el 404 el primer día.
Adam
Hola @Maria_Mercedes_Benco ,
¡Bienvenida a la comunidad!
Escribiste la URL del webhook incorrectamente, por favor actualiza GHL con la siguiente URL:
https://kmb197806.app.n8n.cloud/webhook/ghl-whatsapp-leads
Por favor revisa la siguiente imagen:
Gracias
