Workspace: kmb197806.app.n8n.cloud
ID do Workflow: eRzTqWWhGWWQ2eXP
Nó: Webhook (POST), caminho ghl-whatsapp-leads, webhookId 6bdce384-c129-4223-ab10-238ca40a25db
Problema: Chamadas de webhook de produção de um serviço externo (GoHighLevel) não acionam nenhuma execução no n8n, mesmo que o workflow esteja Ativo/Publicado e o chamador externo receba uma resposta de sucesso.
Passos para reproduzir:
- Workflow ativo e publicado, nó webhook configurado com método POST.
- Serviço externo (GHL) chama a URL de produção: https://kmb197806.app.n8n.cloud/webhook/6bdce384-c129-4223-ab10-238ca40a25db/ghl-whatsapp-leads
- No lado do chamador, o log de requisição mostra “Finished” (implicando que uma resposta de nível 200 foi recebida).
- No n8n, verificando Executions (tanto para este workflow quanto para a conta) mostra nenhuma execução nova foi criada para aquela chamada.
- Uma chamada de modo de produção acionada manualmente para o mesmo webhook (via API) é registrada e executada corretamente.
O que já tentei:
- Recriei o nó Webhook inteiramente (novo webhookId, mesmo caminho/método) — pareceu ajudar temporariamente, depois o mesmo problema recorreu.
- Desativei e republiquei o workflow várias vezes.
- Confirmei que a URL de produção corresponde exatamente ao que está configurado no lado do chamador.
Isso parece estar relacionado a outros relatórios abertos de problemas de registro/sincronização de webhook de produção no n8n Cloud (ex. #16339, #18387, #23808). Agradeceria orientação — isso está bloqueando uma automação de WhatsApp voltada para clientes de ficar ao vivo.
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 @Maria_Mercedes_Benco Bem-vindo(a)!
O webhookId só é adicionado à URL quando o campo Path contém um segmento dinâmico :. ghl-whatsapp-leads é um caminho simples, então a rota de produção registrada é apenas o caminho e o segmento UUID extra faz dela uma rota que o n8n nunca registrou. Ele responde com 404, e o GHL ainda registra isso como Finished, já que esse status é o disparo da etapa em vez do código de resposta que recebeu. Execute isto contra a URL que o GHL está chamando:
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}'
Um corpo 404 nomeando o webhook como não registrado confirma isto. Altere a URL no GHL para:
https://kmb197806.app.n8n.cloud/webhook/ghl-whatsapp-leads
Oi @Maria_Mercedes_Benco
Simplemente alternar o switch “Ativo” do fluxo de trabalho geralmente não é suficiente porque o registro pode estar em cache.
- Desative o fluxo de trabalho.
- Altere o Webhook Path ligeiramente (por exemplo, de
ghl-whatsapp-leads para ghl-whatsapp-leads-v2).
- Salve o fluxo de trabalho.
- Ative o fluxo de trabalho.
- Atualize a URL no GoHighLevel para o novo caminho. Causa raiz: Isso força o n8n a criar uma nova entrada de registro no banco de dados e enviá-la para a camada de ingresso, contornando qualquer cache obsoleto associado ao caminho/ID anterior.
Isso ajuda?
Oi @Maria_Mercedes_Benco
Uma chamada manual em modo de produção para a mesma URL é executada corretamente.
Oi Maria,
Anshul tem a causa raiz no post 2 e eu corrigiria isso primeiro. Mas há uma coisa que ninguém sinalizou, e isso importa mais uma vez que a URL comece a funcionar.
Seu post contém o subdomínio do workspace, o ID do workflow e a URL completa do webhook de produção. Os nós Webhook do n8n não são autenticados por padrão, então no momento em que essa rota for registrada corretamente, qualquer pessoa que ler este tópico poderá fazer POST de JSON arbitrário em uma automação WhatsApp voltada para o cliente. No momento, o 404 é a única coisa protegendo isso.
Duas coisas vale a pena fazer enquanto você está lá. Defina a Autenticação no nó Webhook para Header Auth e escolha um novo caminho em vez de reutilizar esse. A sugestão de kjooleng no post 3 já faz o segundo trabalho, e traz esse benefício também.
A questão mais ampla, e a razão pela qual isso custou dias em vez de minutos: “Finished” no GHL descreve a própria etapa do GHL, não o que aconteceu no outro lado. Quase todas as integrações de saída reportam sua execução em vez da recepção, então um 404, um timeout engolido por um proxy e uma entrega limpa parecem idênticos do lado do envio. Quando um workflow é importante, vale a pena ter o destino confirmar a recepção em vez de confiar na ausência de um erro na origem. Um simples curl manual contra a URL exata que o GHL mantém teria mostrado o 404 no primeiro dia.
Adam
Oi @Maria_Mercedes_Benco,
Bem-vindo(a) à comunidade!
Você digitou a URL do webhook incorreta, por favor atualize o GHL com a URL abaixo:
https://kmb197806.app.n8n.cloud/webhook/ghl-whatsapp-leads
Por favor, verifique a imagem abaixo:
Obrigado
