Descreva o problema/erro/pergunta
Tenho um workflow publicado usando um nó Webhook (configurado com
“Responder: Usando Nó Responder ao Webhook”) atuando como backend
para um aplicativo Google Chat.
Problema:
- Quando envio uma requisição POST manualmente para minha URL de webhook
de produção (via PowerShell/Invoke-RestMethod), funciona perfeitamente:
a execução aparece na aba Execuções, é executada com sucesso e
retorna uma resposta válida.
- Quando o Google Chat envia uma mensagem para a mesma URL de webhook
(configurada em Google Cloud Console > Google Chat API >
Configuração > URL do endpoint HTTP), NENHUMA execução é criada
na aba Execuções do n8n.
- Do lado do Google, o Google Cloud Logging mostra esses erros quando
tenta entregar a mensagem:
- código 3: “Não é possível postar uma resposta. O aplicativo Chat
não respondeu ou sua resposta foi inválida.”
- código 13: “Devido a um erro interno, o Chat falhou ao processar
a resposta do bot”
Isso sugere que a requisição dos servidores do Google Chat não está
alcançando meu workflow (nenhuma execução registrada), enquanto
requisições idênticas de outras fontes o alcançam sem problemas.
Perguntas:
- Há alguma filtragem em nível de Cloudflare/WAF na infraestrutura
compartilhada de webhooks do n8n Cloud que possa estar bloqueando
ou rejeitando requisições especificamente dos servidores da API
Google Chat?
- Existe uma forma de ver logs em nível de borda (antes da execução
do workflow) para confirmar se a requisição está sendo rejeitada
antes de alcançar meu workflow?
Obrigado pela ajuda! Se você tiver mais dúvidas (recurso indisponível),
favor entrar em contato com o suporte em help@n8n.io →
Qual é a mensagem de erro (se houver)?
Compartilhe seu workflow
(Selecione os nós na sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o workflow.)
Compartilhe a saída retornada pelo último nó
Informações sobre sua configuração n8n
- Versão n8n:
- Banco de dados (padrão: SQLite):
- Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
- Executando n8n via (Docker, npm, n8n cloud, aplicativo desktop):
- Sistema operacional:
Oi @Octa-004 Bem-vindo!
Isso é quase certamente a Autenticação do seu nó Webhook, não um bloqueio de edge ou Cloudflare. Google Chat assina cada solicitação com sua própria Authorization: Bearer <JWT> (emitida por chat@system.gserviceaccount.com, User-Agent Google-Dynamite), portanto não pode carregar nenhuma credencial que seu webhook espere. Com autenticação Header, Basic ou JWT habilitada no nó Webhook, n8n rejeita qualquer solicitação cujo token não corresponda e nunca cria uma execução, o que é exatamente por que sua chamada PowerShell com a credencial correta funciona, Google Chat não funciona, e o Google registra “didn’t respond or its response was invalid”.
Defina a Autenticação do nó Webhook como None e republique; as solicitações do Google então chegarão ao workflow e registrarão execuções. Para manter a segurança sem autenticação em nível n8n, verifique o JWT do Google dentro do workflow: um nó Code verificando o emissor chat@system.gserviceaccount.com e o público (número do projeto da sua app ou URL do endpoint), descartando qualquer coisa que falhar.
Sobre suas duas perguntas: n8n Cloud não está bloqueando seletivamente os servidores do Google aqui, e logs de edge pré-execução não são expostos aos usuários, então isso é uma visualização apenas para suporte. Você não precisa deles, pois desativar auth e fazer um novo teste confirma a causa em uma única etapa.
Quando a entrega funcionar, certifique-se de que o nó Respond to Webhook retorna um JSON Chat válido como {"text":"..."} rapidamente, para que você não ative o código 3 por uma resposta genuinamente inválida.
Verify requests from Google Chat | Google for Developers
Excelente diagnóstico de @Anshul_Namdev — a incompatibilidade de autenticação é exatamente por isso que sua chamada manual do PowerShell cria uma execução, mas o Google Chat nunca faz. Google assina toda solicitação com seu próprio JWT Bearer, então qualquer autenticação Header/Basic/JWT no nó Webhook a rejeita antes que uma execução seja criada.
O detalhe que vale a pena adicionar: uma vez que você configura a Autenticação do nó Webhook como “None” para deixar o Chat passar, você não quer deixar o endpoint aberto. Valide o próprio token do Google dentro do fluxo. Coloque um nó Code (ou IF) logo após o Webhook e verifique o JWT Bearer de autorização recebido:
- o emissor (iss) deve ser a conta de serviço do sistema Google Chat (chat@system.gserviceaccount.com, aquela que assina as solicitações do Chat)
- a audiência (aud) deve ser igual ao número de projeto numérico do seu aplicativo Chat
- verifique a assinatura contra os certificados x509 publicados do Google para essa mesma conta de serviço
Se alguma verificação falhar, interrompa o fluxo de trabalho. Apenas o tráfego autêntico do Google Chat carrega um token que passa, então o nó Webhook permanece aberto (as solicitações do Chat finalmente criam execuções) enquanto chamadores aleatórios são filtrados. Isso oferece a mesma proteção que a autenticação do nó estava tentando fornecer, sem bloquear exatamente o remetente que você deseja.
O mesmo sintoma aqui no n8n auto-hospedado 2.2.4, e a explicação de autenticação não se aplica ao meu caso.
Problema
- POST manual para meu URL de webhook de produção (curl, PowerShell) funciona: a execução aparece, é executada e retorna a resposta esperada. HTTP 200.
- Google Chat envia para aquela mesma URL e nenhuma execução é criada. Todas as execuções que este webhook já teve têm user-agent curl/8.5.0 ou PowerShell. Nenhuma solicitação originária do Google jamais apareceu, incluindo uma com falha.
- Google Cloud Logging: código 13, “Due to an internal error, Chat failed to process the bot response”, 18 entradas.
- A autenticação do nó webhook não é a causa. Meus POSTs manuais não enviam cabeçalho Authorization nenhum e ainda assim retornam 200, então o nó não está forçando uma credencial. O workflow não define autenticação — o nó é apenas:
{ “httpMethod”: “POST”, “path”: “my-path”, “responseMode”: “responseNode”, “options”: {} }
typeVersion: 2, nenhuma chave de autenticação. Respond to Webhook com respondWith: json retornando o envelope hostAppDataAction.chatDataAction.createMessageAction.
Já verificado
- URL do endpoint verificado caractere por caractere no console da API Chat, /webhook/ não /webhook-test/.
- “Build as a Workspace add-on” marcado, status do app LIVE, recursos interativos ativados, URL de endpoint HTTP comum para todos os triggers.
- Três reconstruções do zero do app Chat em três novos projetos do Google Cloud. Mesmo resultado cada vez.
Perguntas
- No n8n auto-hospedado, onde uma solicitação que chega ao processo, mas nunca cria uma execução, aparece? N8N_LOG_LEVEL=debug registra um POST para um caminho não registrado, ou há outra forma de confirmar a chegada? Distinguir “Google nunca enviou” de “n8n descartou antes da execução” é o bloqueador.
- Um caminho de webhook de produção pode falhar ao se registrar enquanto o workflow está ativo e a URL retorna 200 para chamadas manuais — após uma importação ou um workflow duplicado? Este foi importado via API REST e contém uma string webhookId legível por humanos em vez de um UUID.
- No console da API Chat, o campo Service Account Email não é renderizado para este app — ausente, não em branco — e nenhuma string gsuiteaddons em lugar nenhum na página. Alguém já viu isso, e indica que a implantação do add-on nunca registrou um alvo de despacho?
Como @JGCoder confirmou que o nó Webhook não usa autenticação e um POST manual não autenticado funciona, eu dividiria o diagnóstico antes de alterar as configurações JWT:
- Verifique o log de acesso do reverse-proxy/ingress enquanto envia um evento de teste do Google Chat. Se nenhuma solicitação de origem do Google aparecer, a falha está acima do n8n: verifique a URL de produção exata do aplicativo Chat, método POST, implantação/disponibilidade e acesso do usuário de teste.
- Se a solicitação aparecer com 30x ou 403, corrija o redirecionamento, WAF ou regra de TLS/proxy.
- Se chegar ao n8n mas não criar nenhuma execução, verifique o registro do webhook publicado além do caminho e método exatos.
Para um teste, reduza o fluxo de trabalho para Webhook (POST, URL de produção) -> Respond to Webhook e retorne HTTP 200 em alguns segundos com {"text":"ok"}. Depois compare a URL e o status mostrados no Google Cloud Logging com o log do proxy. Isso identifica se a falha está na entrega do Google Chat, na edge/proxy ou no próprio n8n.