n8n requested webhook is not registered fix

The exact error often looks like this:

The requested webhook "POST ..." is not registered.
The workflow must be active for a production URL to run successfully.

If the test URL works and the production URL fails, the problem is usually not your JSON body. The root cause is almost always one of these:

1. you are calling the test URL when you mean production
2. the workflow is not actually active
3. you expect production requests to appear on the canvas instead of in Executions

The key distinction: n8n has two webhook URLs#

The n8n webhook docs are explicit:

• Test URL: registered when you click Listen for Test Event or Execute workflow if the workflow is not active
• Production URL: registered when you publish the workflow

That means a successful test call proves only that the test endpoint is alive. It does not prove the production endpoint is registered.

The fix checklist#

1. Confirm you are sending to the right URL#

If you are still developing the workflow manually, use the test URL.

If an external system should call the workflow automatically, use the production URL.

Do not swap them mid-debugging and assume the behavior should match.

2. Activate the workflow#

The GitHub issue reports match what the UI hint says: production URLs need an active workflow.

If you call a production webhook on an inactive workflow, the request is not registered to a live route.

3. Check the Executions tab, not the canvas#

This trips people up constantly. The docs say production webhook data is not displayed on the canvas the way test events are. You inspect those runs from the Executions tab instead.

So if your webhook fires and the canvas looks idle, that does not automatically mean nothing happened.

The most common local-dev confusion#

This sequence produces the error every time:

1. Click Listen for Test Event
2. Verify /webhook-test/... works
3. Copy the production URL into the external service
4. Forget to activate the workflow
5. Get The requested webhook ... is not registered

That is not an n8n parsing bug. It is the expected lifecycle.

What to do if the workflow is active and it still fails#

At that point, recent GitHub issues are worth checking before you blame your payload or headers.

There are real reports from 2025 where API-based deployment or activation failed to register the production webhook path correctly. If you are activating workflows programmatically and the docs-correct steps still do not work, inspect your deployment flow and compare it against issue #21614.

I would debug in this order:

1. activate manually in the UI once
2. retry the production URL
3. inspect the Executions tab
4. if you automate deployment, compare your setup with the recent GitHub issue

A practical team rule#

Treat test and production URLs as different products:

• test URL for manual development
• production URL for real integrations

When you keep that boundary clear, this whole class of webhook confusion almost disappears.

For more n8n production work:

• n8n Complete Beginner Guide 2026: Build Your First Automation Workflow
• How I Fixed My n8n Workflow That Was Failing Silently for Three Weeks
• n8n Client Reporting Workflow: ClickUp, Toggl and Gmail
• Migrating from Zapier to n8n: Docker Setup and Zap Mapping

References#

• n8n docs: Webhook node
• GitHub issue #21614: workflow must be active for a production URL
• GitHub issue #15666: production webhook not registered, test webhook works

Queue mode changes who answers the webhook, not whether it's registered#

If you're past a single-instance setup and running n8n in queue mode — a main process plus separate worker processes pulling jobs from Redis — the webhook-not-registered error has an extra wrinkle worth ruling out before you re-check activation for the tenth time. Queue mode does not move webhook handling out to the workers: the main instance (or a dedicated webhook process, if you've split one out) is still the one that receives the incoming HTTP request and registers the route. Workers only execute the workflow logic once the main process hands them the job. That split matters for two failure modes that look identical to a plain "not registered" error but have a different cause:

1. If you scaled up workers but never separately confirmed the main/webhook process itself is healthy and reachable, adding workers does nothing for webhook registration — they were never in that path to begin with.
2. If you're running multiple main instances behind a load balancer without pinning webhook traffic to the one that actually activated the workflow, the request can land on an instance that never registered that route.

The full breakdown of what runs where in this architecture, including the environment variables that wire main/worker/Redis together, is in n8n Queue Mode: The Redis + Postgres Checklist. The short version for this error specifically: in queue mode, "is the workflow active" is necessary but no longer sufficient — you also need to confirm which process is supposed to be answering the webhook, and that it's the one actually receiving the request.

When the workflow is active but the public URL doesn't match what n8n registered#

There's a failure mode that survives every check in this article's fix list: the workflow is active, you're calling the production path, and you're reading the Executions tab — and it still says not registered. This happens when n8n is running behind a reverse proxy, tunnel, or container network where the address n8n thinks it's reachable at doesn't match the address the external caller is actually hitting.

n8n builds the webhook URLs it displays in the editor (and registers internally) from its own configured base URL. If that's left at a default like localhost or an internal Docker hostname while the workflow is actually exposed to the internet through a proxy or tunnel on a different public hostname, the URL the editor shows you and the URL your external service is calling can diverge — the registration exists, just not at the address you assumed. This is exactly the class of mismatch covered from the routing side for calling services in n8n 'No testing function found for this credential' Fix, where a similarly invisible internal/external gap causes a credential-facing symptom instead of a webhook one.

Before assuming this is your case, confirm the workflow's displayed production URL matches, byte for byte, the URL the external service is configured to call — including protocol and trailing path segments. A single-character mismatch in a copy-pasted hostname reproduces this exact error message with an active workflow and a correct Executions-tab check.

Further reading: n8n Microsoft OAuth2: Fix 'Need Admin Approval'. Also see n8n Error Workflow Not Triggering: 5 Real Causes.