Production webhook shows "Finished" in caller's log but never triggers execution (n8n Cloud)

Questions
1

Workspace: kmb197806.app.n8n.cloud
Workflow ID: eRzTqWWhGWWQ2eXP
Node: Webhook (POST), path ghl-whatsapp-leads, webhookId 6bdce384-c129-4223-ab10-238ca40a25db
Issue: Production webhook calls from an external service (GoHighLevel) do not trigger any execution in n8n, even though the workflow is Active/Published and the external caller receives a success response.
Steps to reproduce:

  1. Workflow is active and published, webhook node configured with POST method.
  2. External service (GHL) calls the production URL: https://kmb197806.app.n8n.cloud/webhook/6bdce384-c129-4223-ab10-238ca40a25db/ghl-whatsapp-leads
  3. On the caller’s side, the request log shows “Finished” (implying a 200-level response was received).
  4. In n8n, checking Executions (both for this workflow and account-wide) shows no new execution was created for that call.
  5. A manually triggered production-mode call to the same webhook (via API) does register and execute correctly.
    What I’ve tried:
  • Recreated the Webhook node entirely (new webhookId, same path/method) — temporarily seemed to help, then same issue recurred.
  • Deactivated and republished the workflow multiple times.
  • Confirmed the production URL matches exactly what’s configured on the caller’s side.
    This appears related to other open reports of production webhook registration/sync issues on n8n Cloud (e.g. #16339, #18387, #23808). Would appreciate guidance — this is blocking a client-facing WhatsApp automation from going live.

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

Hi @Maria_Mercedes_Benco Welcome!
The webhookId is only prepended to the URL when the Path field contains a dynamic : segment. ghl-whatsapp-leads is a plain path, so the registered production route is just the path and the extra UUID segment makes it a route n8n never registered. It answers 404, and GHL still logs that as Finished, since that status is the step firing rather than the response code it got back. Run this against the URL GHL is calling:

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}'

A 404 body naming the webhook as not registered confirms it. Change the URL in GHL to:

https://kmb197806.app.n8n.cloud/webhook/ghl-whatsapp-leads
3

Hi @Maria_Mercedes_Benco

Simply toggling the workflow “Active” switch often isn’t enough because the registration might be cached.

  1. Deactivate the workflow.
  2. Change the Webhook Path slightly (e.g., from ghl-whatsapp-leads to ghl-whatsapp-leads-v2).
  3. Save the workflow.
  4. Activate the workflow.
  5. Update the URL in GoHighLevel to the new path. Root Cause: This forces n8n to create a brand new registration entry in the database and push it to the ingress layer, bypassing any stale cache associated with the previous path/ID.

Does that help?

4

Hi @Maria_Mercedes_Benco

Is a manual production-mode call to the same URL executes correctly.

5

Hi Maria,

Anshul has your root cause in post 2 and I would fix that first. One thing nobody has flagged though, and it matters more once the URL starts working.

Your post contains the workspace subdomain, the workflow ID and the full production webhook URL. n8n Webhook nodes are unauthenticated by default, so the moment that route is registered correctly, anyone who reads this thread can POST arbitrary JSON into a client facing WhatsApp automation. Right now the 404 is the only thing protecting it.

Two things worth doing while you are in there. Set Authentication on the Webhook node to Header Auth, and pick a new path rather than reusing this one. kjooleng’s suggestion in post 3 already does the second job, it just has this benefit as well.

The wider thing, and the reason this cost you days rather than minutes: “Finished” in GHL describes GHL’s own step, not what happened at the other end. Almost every outbound integration reports on its execution rather than on receipt, so a 404, a timeout swallowed by a proxy, and a clean delivery all look identical from the sending side. When a workflow matters, it is worth having the destination confirm receipt rather than trusting the absence of an error at the source. One manual curl against the exact URL GHL holds would have shown the 404 on day one.

Adam

6

Hi @Maria_Mercedes_Benco ,

Welcome to the community!

You typed the wrong webhook url, please update GHL with the below url:

https://kmb197806.app.n8n.cloud/webhook/ghl-whatsapp-leads

Please check the below image:

image
image1645×694 39.8 KB

Thanks