n8n Webhook Not Working? Test URL, Production URL, and 404 Fixes

An n8n webhook normally fails before the first workflow node runs. A 404 usually means the request did not match a registered webhook route. The common causes are a test URL with no active listener, a production URL for an unpublished workflow, the wrong HTTP method, a changed path, or an incorrect public URL on a self-hosted instance.

Start with the symptom

Test URL versus Production URL

Every Webhook node exposes two URLs at the top of its panel. The official Webhook node documentation treats them as two different operating modes, not interchangeable copies of the same endpoint.

Use the Test URL while building

Select Test URL, then select Listen for test event before the external system sends its request. n8n registers the test webhook for 120 seconds and displays the incoming data in the editor. If the timer expires, register it again and resend the event.

Opening the workflow is not enough by itself. A saved test URL can return 404 later because test registration is temporary. This is useful during development because it lets one test payload appear directly on the canvas, but it is the wrong URL for a service that must call n8n at any time.

Use the Production URL after publishing

Select Production URL, copy it into the sending service, and Publish the workflow. Current n8n documentation uses Publish terminology. Publishing registers the production webhook and makes the published workflow version available to external requests until the workflow is unpublished.

Production payloads do not appear live on the editor canvas. Open Executions to confirm whether the request created a production execution and to inspect its input. No data on the canvas does not mean the webhook failed.

The n8n webhook 404 checklist

Run these checks in order. Stop as soon as the request reaches n8n.

1. Copy the URL from the node again. Do not rely on a URL saved in an old note, form, app, or API client.
2. Confirm Test or Production. Test requires a temporary listener. Production requires a published workflow.
3. Confirm the HTTP method. A POST request does not match a webhook registered only for GET.
4. Compare the path exactly. Check spelling, hyphens, route parameters, and any path changed after the sender was configured.
5. Check for a path-and-method conflict. n8n permits only one registered webhook for each path and method combination.
6. Inspect the public base URL. Do this only for self-hosted n8n behind a reverse proxy or when the node displays an internal hostname, HTTP instead of HTTPS, or the wrong port.

Check the HTTP method before the payload

The Webhook node supports GET, POST, PUT, PATCH, DELETE, and HEAD. By default it accepts one method. The sender must use that exact method. Pasting a webhook URL into a browser sends GET, so a successful browser test does not prove that a service's POST request will match, and the reverse is also true.

Current n8n versions can allow multiple HTTP methods from the node's Settings. Use that only when the endpoint genuinely needs more than one method. A tighter single-method webhook is easier to reason about and reduces accidental calls.

Check the webhook path

n8n generates a random path by default, and you can replace it with a stable custom path. Once an external app stores the URL, changing the Path field changes the route it must call. Copy the complete URL after every path change instead of editing only the last segment by hand.

n8n also requires each registered path and HTTP method combination to be unique. If another published workflow already owns the same combination, unpublish the conflicting workflow or choose a different path or method. The Webhook common-issues page documents both method matching and route conflicts.

Send a minimal request

Remove the external app from the diagnosis. Copy the exact URL from the Webhook node and test it with a safe placeholder payload. The example below uses POST. Change the method if your node uses something else.

curl --request POST 'https://n8n.example.com/webhook/example-path' \
  --header 'Content-Type: application/json' \
  --data '{"event":"webhook-test","id":"demo-001"}'

Replace the example URL with the full Test or Production URL copied from your node. For a Test URL, select Listen for test event immediately before running the command. For a Production URL, publish first. If this request works, the remaining problem is in the external app's stored URL, method, headers, authentication, or network access.

Reverse proxy and public URL problems

Skip this section on n8n Cloud. It matters when a self-hosted instance runs internally on one address but a reverse proxy exposes a different public HTTPS address.

n8n normally builds webhook URLs from N8N_PROTOCOL, N8N_HOST, and N8N_PORT. Behind a proxy, that can produce an internal port or the wrong scheme. The official reverse-proxy configuration says to set the public URL explicitly with WEBHOOK_URL, set N8N_PROXY_HOPS to the number of reverse proxies, and pass the forwarded host, protocol, and client information from the last proxy.

WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1

What to log before handing the webhook into production

• The final Production URL location and which external system owns it. Do not paste secret query parameters into a public document.
• The expected HTTP method, content type, authentication method, and a sanitized example payload.
• The workflow owner and where production executions are reviewed.
• The expected success response and what the sender does when it receives a non-2xx response.
• The alert channel and recovery owner for failures after the webhook starts the workflow.

Once the route works, broader failures belong in the n8n workflow debugging guide. Production ownership and notifications belong in the n8n error workflow alerts guide. Keeping those jobs separate makes the webhook checklist short enough to use during an incident.

The production handoff

1. Test with the Test URL and one sanitized payload.
2. Switch the node to Production URL and copy the full value.
3. Publish the workflow.
4. Update the external service with the Production URL and matching method.
5. Trigger one real but safe event.
6. Confirm the run in Executions and record who owns failures.

n8n autosaves edits, but saved draft changes are not the same as the published version used by production executions. The save and publish documentation explains that production runs continue to use the current published version until you publish newer changes.