Describir el problema/error/pregunta
Tengo un flujo de trabajo publicado que utiliza un nodo Webhook (configurado con
“Responder: Usando Nodo Responder a Webhook”) actuando como backend para
una aplicación de Google Chat.
Problema:
- Cuando envío una solicitud POST a mi URL de webhook de producción manualmente
(mediante PowerShell/Invoke-RestMethod), funciona perfectamente: la
ejecución aparece en la pestaña Ejecuciones, se ejecuta correctamente y
devuelve una respuesta válida.
- Cuando Google Chat envía un mensaje a la misma URL de webhook exacta
(configurada en Google Cloud Console > API de Google Chat >
Configuración > URL del punto de conexión HTTP), NUNCA se crea ninguna ejecución
en la pestaña Ejecuciones de n8n.
- En el lado de Google, Google Cloud Logging muestra estos errores cuando intenta
entregar el mensaje:
- código 3: “No se puede publicar una respuesta. La aplicación de Chat no respondió o
su respuesta fue inválida.”
- código 13: “Debido a un error interno, Chat no pudo procesar la
respuesta del bot”
Esto sugiere que la solicitud de los servidores de Google Chat no llega
a mi flujo de trabajo en absoluto (ninguna ejecución registrada), mientras que solicitudes idénticas
de otras fuentes la alcanzan sin problemas.
Preguntas:
- ¿Hay algún filtrado a nivel de Cloudflare/WAF en la infraestructura compartida de webhooks de n8n Cloud que podría bloquear o rechazar
solicitudes específicamente de los servidores de API de Google Chat?
- ¿Hay alguna forma de ver registros a nivel de borde (antes de la ejecución del flujo de trabajo)
para confirmar si la solicitud se rechaza antes de llegar a mi flujo de trabajo?
¡Gracias por tu ayuda! (Si necesitas ayuda adicional que no esté disponible aquí, por favor contacta con el equipo de soporte en help@n8n.io)
¿Cuál es el mensaje de error (si lo hay)?
Por favor, comparte tu flujo de trabajo
(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 de trabajo.)
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 de EXECUTIONS_PROCESS de n8n (predeterminado: own, main):
- Ejecutando n8n mediante (Docker, npm, n8n cloud, aplicación de escritorio):
- Sistema operativo:
¡Hola @Octa-004! ¡Bienvenido!
Esto casi seguramente es la Autenticación de tu nodo Webhook, no un bloqueo de edge o Cloudflare. Google Chat firma cada solicitud con su propio Authorization: Bearer <JWT> (emitido por chat@system.gserviceaccount.com, User-Agent Google-Dynamite), por lo que no puede llevar la credencial que tu webhook espera. Con autenticación Header, Basic o JWT habilitada en el nodo Webhook, n8n rechaza cualquier solicitud cuyo token no coincida y nunca crea una ejecución, que es exactamente por qué tu llamada PowerShell con la credencial correcta funciona, Google Chat no, y Google registra “no respondió o su respuesta no fue válida”.
Establece la Autenticación del nodo Webhook en None y vuelve a publicar; las solicitudes de Google entonces llegarán al flujo de trabajo y registrarán ejecuciones. Para mantenerte seguro sin autenticación a nivel de n8n, verifica el JWT de Google dentro del flujo de trabajo en su lugar: un nodo Code que verifique el emisor chat@system.gserviceaccount.com y la audiencia (el número de proyecto de tu aplicación o URL del endpoint), descartando cualquier cosa que falle.
Sobre tus dos preguntas: n8n Cloud no está bloqueando selectivamente los servidores de Google aquí, y los registros de edge previos a la ejecución no se exponen a los usuarios, así que eso es una vista solo para soporte. No los necesitas, ya que desactivar la autenticación y volver a probar confirma la causa en un paso.
Una vez que la entrega funcione, asegúrate de que el nodo Respond to Webhook devuelva JSON válido de Chat como {"text":"..."} rápidamente, para que no actives el código 3 por una respuesta genuinamente inválida.
Verify requests from Google Chat | Google for Developers
Buen diagnóstico de @Anshul_Namdev — la falta de coincidencia de autenticación es exactamente por qué tu llamada manual de PowerShell crea una ejecución pero Google Chat nunca lo hace. Google firma cada solicitud con su propio JWT Bearer, por lo que cualquier autenticación Header/Basic/JWT en el nodo Webhook la rechaza antes de que se cree una ejecución.
Lo que vale la pena agregar: una vez que configures la autenticación del nodo Webhook en “None” para permitir que Chat pase, no quieres dejar el endpoint completamente abierto. En su lugar, valida el propio token de Google dentro del flujo. Coloca un nodo Code (o IF) justo después del Webhook y verifica el JWT Bearer de autorización entrante:
- el emisor (iss) debe ser la cuenta de servicio del sistema de Google Chat (chat@system.gserviceaccount, la que firma las solicitudes de Chat)
- la audiencia (aud) debe ser igual al número de proyecto numérico de tu aplicación de Chat
- verifica la firma contra los certificados x509 publicados de Google para esa misma cuenta de servicio
Si alguna verificación falla, detén el flujo de trabajo. Solo el tráfico auténtico de Google Chat lleva un token que pasa, por lo que el nodo Webhook permanece abierto (las solicitudes de Chat finalmente crean ejecuciones) mientras que los llamadores aleatorios se filtran. Esto te da la misma protección que la autenticación del nodo intentaba proporcionar, sin bloquear al remitente exacto que deseas.
El mismo síntoma aquí en n8n autohospedado 2.2.4, y la explicación de autenticación no se ajusta a mi caso.
Problema
- POST a mi URL de webhook de producción manualmente (curl, PowerShell) funciona: la ejecución aparece, se ejecuta, devuelve la respuesta esperada. HTTP 200.
- Google Chat envía a esa misma URL y no se crea ninguna ejecución. Todas las ejecuciones que este webhook ha tenido tienen user-agent curl/8.5.0 o PowerShell. Ninguna solicitud originada por Google ha aparecido nunca, ni siquiera una fallida.
- Google Cloud Logging: código 13, «Debido a un error interno, Chat no pudo procesar la respuesta del bot», 18 entradas.
- La autenticación del nodo Webhook no es la causa. Mis POSTs manuales no envían ningún encabezado Authorization y aún devuelven 200, por lo que el nodo no está aplicando una credencial. El flujo de trabajo no establece autenticación — el nodo es simplemente:
{ “httpMethod”: “POST”, “path”: “my-path”, “responseMode”: “responseNode”, “options”: {} }
typeVersion: 2, sin clave de autenticación. Responder a Webhook es respondWith: json devolviendo el sobre hostAppDataAction.chatDataAction.createMessageAction.
Ya verificado
- URL del endpoint verificada carácter por carácter en la consola de Chat API, /webhook/ no /webhook-test/.
- «Build as a Workspace add-on» marcado, estado de la app LIVE, características interactivas activadas, URL de endpoint HTTP común para todos los disparadores.
- Tres reconstrucciones desde cero de la app de Chat en tres nuevos proyectos de Google Cloud. Mismo resultado cada vez.
Preguntas
- En n8n autohospedado, ¿dónde aparece una solicitud que llega al proceso pero nunca crea una ejecución? ¿N8N_LOG_LEVEL=debug registra un POST a una ruta no registrada, o hay otra forma de confirmar la llegada? Distinguir «Google nunca la envió» de «n8n la descartó antes de la ejecución» es el bloqueador.
- ¿Puede una ruta de webhook de producción no registrarse mientras el flujo de trabajo está activo y la URL devuelve 200 a llamadas manuales — después de una importación, o un flujo de trabajo duplicado? Este fue importado a través de la API REST y lleva una cadena webhookId legible por humanos en lugar de un UUID.
- En la consola de Chat API, el campo Service Account Email no se renderiza en absoluto para esta app — ausente, no en blanco, y ninguna cadena gsuiteaddons en ningún lugar de la página. ¿Alguien ha visto eso, e indica que la implementación del complemento nunca registró un destino de envío?
Dado que @JGCoder ha confirmado que el nodo Webhook no utiliza autenticación y una POST manual sin autenticar funciona, dividiría el diagnóstico antes de cambiar la configuración de JWT:
- Comprueba el registro de acceso del proxy inverso/ingress mientras envías un evento de prueba de Google Chat. Si no aparece ninguna solicitud de origen de Google, el fallo está antes de n8n: verifica la URL de producción exacta de la aplicación Chat, el método POST, la implementación/disponibilidad y el acceso del usuario de prueba.
- Si la solicitud aparece con 30x o 403, corrige la redirección, WAF o regla de TLS/proxy.
- Si llega a n8n pero no crea ninguna ejecución, verifica el registro del webhook publicado más la ruta y el método exactos.
Para una prueba, reduce el flujo de trabajo a Webhook (POST, URL de producción) -> Responder al Webhook y devuelve HTTP 200 en pocos segundos con {"text":"ok"}. Luego compara la URL y el estado que se muestran en Google Cloud Logging con el registro del proxy. Eso identifica si el fallo está en la entrega de Google Chat, en el edge/proxy o en el propio n8n.