n8n · troubleshooting · reproduced on n8n 2.25.7, 6 September 2026

n8n webhook not registered

n8n answers with HTTP 404 and a JSON body whose hint field already names your fix. There are two hints and they mean different things: the production hint means the workflow is not published, and the test hint means you called a /webhook-test/ URL without clicking Execute workflow first. The request did reach n8n — that is why you got JSON rather than a connection error — so the network, DNS and TLS are not the problem.

Below: both bodies exactly as our instance returned them, the six causes that produce them, and the order to check things in. Everything marked “reproduced” was run against n8n 2.25.7 in Docker on 6 September 2026.

The two responses, verbatim

Production URL — a GET to a path no published workflow owns:

$ curl -i http://localhost:5678/webhook/does-not-exist
HTTP/1.1 404 Not Found
Content-Type: application/json; charset=utf-8

{"code":404,
 "message":"The requested webhook \"GET does-not-exist\" is not registered.",
 "hint":"The workflow must be active for a production URL to run
         successfully. You can activate the workflow using the toggle
         in the top-right of the editor. Note that unlike test URL
         calls, production URL calls aren't shown on the canvas
         (only in the executions list)"}

Test URL — the same request against /webhook-test/:

$ curl http://localhost:5678/webhook-test/does-not-exist
{"code":404,
 "message":"The requested webhook \"does-not-exist\" is not registered.",
 "hint":"Click the 'Execute workflow' button on the canvas, then try
         again. (In test mode, the webhook only works for one call
         after you click this button)"}

Line breaks added for readability; the wording is unchanged. Reproduced on n8n 2.25.7, 6 September 2026. Note that the production message includes the HTTP method ("GET does-not-exist") and the test message does not — a fast way to tell the two apart when all you have is a log line.

There is a third wording. When n8n does have that path registered but under other methods, its error builder returns This webhook is not registered for POST requests. Did you mean to make a GET request? — with the methods it knows about filled in. If you see that sentence, the path is right and only the verb is wrong.

Six causes, and how to tell which is yours

Cause	How it shows up	Fix
The workflow is not published	Production hint, and the workflow shows as a draft in the editor.	Publish it. In n8n 2.x the CLI makes the rename explicit: n8n update:workflow --id=X --active=true answers “Please use: publish:workflow --id=X”.
You are calling the test URL without arming it	Test hint, and the path contains /webhook-test/.	Click Execute workflow in the editor first. Per n8n’s docs the test URL listens for 120 seconds; the production URL listens until the workflow is unpublished.
Right path, wrong HTTP method	GET and POST to the same path behave differently; sometimes the message names the methods that would work.	Match the node’s method, or turn on Allow Multiple HTTP Methods — the docs note that with it on, the node “now accepts GET and POST calls” by default.
Another workflow already owns the path	A message that the path and method are already in use, usually right after you publish.	n8n “only permits registering one webhook for each path and HTTP method combination.” Unpublish the conflicting workflow, or change the path or method on one of them.
The instance is still booting	Intermittent — the first calls after a restart 404, later ones work.	Wait for the log line Activated workflow "<name>" (ID: …). We hit this ourselves: curl calls fired between “Start Active Workflows:” and that line all returned the 404 below.
A reverse proxy is rewriting or hiding the path	The URL shown in the editor is not the URL that reaches n8n.	n8n builds the webhook URL from N8N_PROTOCOL, N8N_HOST and N8N_PORT, which the docs say “won’t work” behind a proxy; set N8N_WEBHOOK_URL to the public base URL instead. From n8n 2.35.0 the old WEBHOOK_URL is a deprecated alias and logs a warning at startup.

The order to check things in

Read the hint field, not just the messageProduction hint → publication state. Test hint → you need to click Execute workflow first. This single step settles most cases and costs nothing.
Confirm the path n8n actually seesCall a path you know is wrong, e.g. curl http://your-n8n/webhook/definitely-not-a-path. If that returns the n8n JSON 404, requests are reaching n8n and the proxy is fine. If it returns your proxy’s HTML error page instead, the problem is in front of n8n.
Try the test URLClick Execute workflow, then call the /webhook-test/ URL within the 120 seconds the docs give you. Success here proves node, path and method are correct and points the finger at publication or the proxy.
Check for a path collisionOne webhook per path + method, per the docs. If you duplicated a workflow, the copy is the usual culprit — unpublish it or change its path.
Watch the startup logThe production webhook is registered when Activated workflow "<name>" appears. Calls made before that line return the 404 even though everything is configured correctly.
Only then look at environment variablesBehind a proxy, set N8N_WEBHOOK_URL to the public base URL; WEBHOOK_URL is a deprecated alias from n8n 2.35.0 and logs a warning. Set N8N_PROXY_HOPS to the number of proxies if IP restrictions are involved.

A webhook you can test against

If you want a known-good workflow to compare behaviour with, three of our free templates are webhook-triggered and need no credentials at all: the webhook JSON API endpoint, the form validation API and the event router. Import one, publish it, call it — if that works and yours does not, the difference is in your workflow, not in the instance. Our import guide walks through the file import, and “Could not import file” covers what to do when that step itself fails.

One budgeting note that surprises people: every call to a published webhook is one execution, whatever the workflow does afterwards. Our n8n pricing page works through what that costs per plan.

Sources and last verified

Error bodies reproduced on n8n 2.25.7 in Docker on 6 September 2026. Documented behaviour comes from the pages below, read the same day.

n8n Docs — Webhook node, common issues (test vs production URL, conflicting webhooks, N8N_PROXY_HOPS) — checked 2026-09-06
n8n Docs — Configure webhook URLs with a reverse proxy (N8N_WEBHOOK_URL) — checked 2026-09-06
n8n source — the error and its two hints (webhook-not-found.error.ts) — checked 2026-09-06

Frequently asked questions

What does “The requested webhook is not registered” mean in n8n?

It means n8n received your HTTP request but has no webhook listening on that path and method right now. n8n returns HTTP 404 with a JSON body containing code, message and hint. It is not a networking failure — the request reached n8n, which is why you get JSON back rather than a connection error.

What is the difference between the two hints?

The production hint reads “The workflow must be active for a production URL to run successfully…” and means you called a /webhook/ URL on a workflow that is not published. The test hint reads “Click the ‘Execute workflow’ button on the canvas, then try again. (In test mode, the webhook only works for one call after you click this button)” and means you called a /webhook-test/ URL without arming it first. Read the hint before changing anything: they have different fixes.

Why does my test URL work but the production URL 404?

The test URL is armed by clicking Execute workflow and, per n8n’s docs, listens for 120 seconds; the production URL only exists while the workflow is published. A test URL that works proves the node, the path and the method are right, and narrows the problem to publication state or to a proxy in front of the production path.

Does n8n let two workflows share a webhook path?

No. n8n’s documentation states it “only permits registering one webhook for each path and HTTP method combination” to avoid ambiguity about which webhook should receive the request. The documented fixes are to unpublish the workflow holding the conflicting webhook, or change the path or the method on one of them.

The workflow is published and the log says “Activated workflow”, but the production URL still 404s. What now?

We reproduced exactly that on n8n 2.25.7: a workflow imported with n8n import:workflow and published with n8n publish:workflow showed active=1 in the database and printed Activated workflow in the log, yet POST to its production URL still returned the 404. We could not get a CLI-only import to serve a production webhook on that version. Opening the workflow in the editor and publishing it there is the path n8n documents, and it is what we recommend before spending time on the proxy layer.

Can a reverse proxy cause this?

Yes, in two ways. If the proxy strips or rewrites the path prefix, n8n receives a path it has nothing registered for. And if n8n does not know its public URL, the editor shows a URL that is not the one you should call — n8n builds it from N8N_PROTOCOL, N8N_HOST and N8N_PORT, which the docs say will not work behind a proxy, and tells you to set N8N_WEBHOOK_URL instead. Separately, the docs recommend setting N8N_PROXY_HOPS to the number of reverse proxies in front of n8n when IP-based restrictions misbehave.