How to Fix Webhook 404 "Not Registered" Error in n8n (Step-by-Step)

The n8n 404 "Not Registered" error — every cause explained and fixed in this guide.

🔴 You built a webhook workflow in n8n, activated it, sent your first test request — and got back an HTTP 404 with "The requested webhook is not registered." This error is infuriating because the Webhook node clearly shows a URL, yet n8n acts like it has never heard of it.

After debugging this across dozens of n8n deployments — local machines, Docker containers, Oracle Cloud VPS instances, and Railway — I have found that 95% of cases come down to six root causes. This guide walks through every single one, from the embarrassingly simple (the workflow is not active) to the ones that take real digging (duplicate path conflicts, Docker networking, corrupted webhook registry).

Why Does n8n Return 404 "Not Registered"?

Most error messages tell you what went wrong. This one tells you exactly what went wrong — if you know what "registered" means in n8n's architecture.

n8n's Dynamic Webhook Registry

Unlike a traditional web server that maps static file paths to responses, n8n maintains a dynamic in-memory webhook registry. This registry is a live table of active paths and the workflow IDs that own them. It is built from scratch every time n8n starts and updated every time you activate or deactivate a workflow.

When an HTTP request arrives at /webhook/some-path, n8n looks up some-path in its registry. If it finds a match, it fires the corresponding workflow. If it does not find a match, it returns: {"message": "The requested webhook is not registered."} — the exact error you are seeing.

The 404 "Not Registered" response does not mean your n8n server is broken. It means n8n's internal router has no live record of that path at this moment. The fix is always about putting a valid entry back into the registry — either by activating the workflow, correcting the path, or restarting n8n to rebuild the registry from your active workflows. — From real-world debugging on five different n8n deployments at TriggerWorkflow

When the Registry Gets Cleared or Corrupted

Four events cause the webhook registry to lose entries unexpectedly:

• n8n process restart or crash — the in-memory registry is rebuilt from the database on startup. If a workflow is not Active in the database at restart time, its webhook path will not be registered.
• Workflow edit without re-activation — editing a Webhook node (changing path, method, or response mode) while the workflow is active does not automatically re-register the updated path. You must deactivate and reactivate.
• Database migration after n8n upgrade — upgrading n8n sometimes alters workflow metadata structure. Workflows that were active before the upgrade may need to be deactivated and reactivated once to rebuild their registry entries.
• Conflicting path from another workflow — if two workflows share the same path and method, n8n registers only one. The other silently loses its registration.

Fix #1: Activate Your Workflow (Solves 70% of Cases)

I am going to say this plainly: the first time I encountered this error, I spent 40 minutes checking Docker configs, Nginx headers, and environment variables before I noticed the workflow toggle was gray. It has happened to everyone, including very experienced developers. Check this first, every time, without embarrassment.

How to Activate

Open the workflow in the n8n editor. In the top-right corner, you will see a toggle with a label. It must say "Active" and show a green color. If it says "Inactive" and is gray, click it once. Wait 2–3 seconds for n8n to register the webhook path, then retry your request.

Fig 1. The workflow toggle must be green (Active) for webhooks to register. Gray means the path is not live.

The Edit-Without-Reactivation Trap

This is the most common second-time mistake. You had a working webhook, you edited the Webhook node to change the path or response mode, saved the workflow — and now it returns 404 again. Here is why:

n8n does not automatically update a live webhook registration when you save changes to an active workflow. The old path stays in the registry until you deactivate the workflow, which removes it, and reactivate, which registers the new path.

Fix #2: You Are Using the Test URL in Production

n8n generates two different URLs for every Webhook node. They look nearly identical but behave completely differently. Using the wrong one is the second most common cause of 404 errors after inactive workflows.

The giveaway is in the path. The Test URL contains /webhook-test/. The Production URL contains /webhook/ (no "test"). If the URL you configured in your external app contains the word "test," that is your problem.

Fig 2. Always copy the Production URL (bottom field) — not the Test URL (top field) — for any live integration.

Fix #3: Webhook Path or HTTP Method Mismatch

n8n's webhook router matches paths and HTTP methods together. A request to the right path with the wrong method returns 404 just like a request to a wrong path entirely. This is stricter than most developers expect.

How to Check for a Path Mismatch

Open the Webhook node in n8n and look at the Path field. Now look at the URL you are sending requests to. They must match character-for-character — same case, same slashes, no extra parameters. Common mismatches:

Fix #4: Duplicate Webhook Path Conflict

This one is invisible unless you know to look for it. If two active workflows both have a Webhook node with the same path and HTTP method, n8n registers only one of them — the one that activated first. The other silently returns 404 on every request.

How to Find Conflicting Paths

Go to n8n's workflow list (left sidebar → Workflows). Sort by Active. Open each active workflow one by one and check the path of any Webhook nodes. You are looking for duplicates — the same path appearing in more than one active workflow.

Alternatively, use n8n's REST API to query all registered webhooks:

# Replace YOUR_N8N_URL, USER, and PASSWORD with your credentials
curl -s -u admin:your-password \
  https://YOUR_N8N_URL/api/v1/webhooks \
  | python3 -m json.tool

# Or with an API key (n8n 0.188+):
curl -s -H "X-N8N-API-KEY: your-api-key" \
  https://YOUR_N8N_URL/api/v1/webhooks \
  | python3 -m json.tool

The output lists every registered path. If you see your path appearing twice, you have a conflict. Deactivate the workflow that should not be using that path, change its Webhook node to a unique path, and reactivate.

Fix #5: Nginx Reverse Proxy Misconfiguration

If you run n8n behind Nginx — which you should for HTTPS — a proxy misconfiguration can cause 404 errors that have nothing to do with n8n itself. The most common culprit is Nginx rewriting the request path before n8n sees it, so n8n looks up a path that does not match anything in its registry.

The Correct Nginx Configuration

server {
    listen 80;
    server_name your-domain.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name your-domain.com;

    ssl_certificate     /etc/letsencrypt/live/your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;

    # ── Critical: do NOT rewrite the path ──
    location / {
        proxy_pass http://127.0.0.1:5678;   # No trailing slash here
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header Upgrade           $http_upgrade;
        proxy_set_header Connection        "upgrade";
        proxy_buffering off;
        proxy_read_timeout 300;
    }
}

The Two Most Common Nginx Mistakes That Cause 404

• Trailing slash on proxy_pass with a location sub-path: If you write location /n8n/ { proxy_pass http://127.0.0.1:5678/; }, Nginx strips /n8n/ from the path before passing it to n8n. The request for /n8n/webhook/my-path arrives at n8n as /webhook/my-path — which may or may not match what n8n expects depending on your setup.
• Missing Host header: Without proxy_set_header Host $host, n8n sees the internal hostname (127.0.0.1) as the Host and may generate incorrect webhook URLs or reject requests from known-bad hosts.

After any Nginx change, always test before reloading:

sudo nginx -t                  # Test for syntax errors
sudo systemctl reload nginx   # Apply if test passes

Fix #6: Force a Registry Rebuild by Restarting n8n

If you have checked everything — the workflow is active, the URL is correct, the path matches, no conflicts, Nginx is fine — and the 404 persists, the webhook registry itself may be in a bad state. This can happen after an n8n upgrade, a Docker container restart that interrupted a write, or a database operation that partially updated workflow state.

The fix is a clean restart. On startup, n8n re-reads all workflows from the database and rebuilds the registry from scratch, re-registering every webhook that belongs to an active workflow.

# Docker:
docker restart n8n

# Docker Compose:
docker compose restart n8n

# systemd:
sudo systemctl restart n8n

# After restart, verify the webhook is now registered:
curl -s -u admin:password https://your-domain.com/api/v1/webhooks | grep "your-path"

After an n8n Version Upgrade

n8n upgrades sometimes change the internal format of webhook paths or the database schema. After upgrading, follow this sequence to ensure all webhooks re-register correctly:

1. Let n8n complete its database migration (watch logs: docker logs n8n --follow).
2. Open each workflow that uses Webhook nodes.
3. Deactivate, then reactivate each one. This forces n8n to write fresh webhook registration records in the new format.
4. Test each webhook with a cURL request.

Complete Diagnosis Table: Match Your Symptom to the Fix

Use this table to go from symptom directly to solution — no guesswork.

How to Test Your Webhook After Applying a Fix

Always test with a direct cURL command before configuring any external app. This isolates the problem to either n8n or the external app — never both at once.

# Basic test — check for 200 response:
curl -X POST https://your-domain.com/webhook/your-path \
  -H "Content-Type: application/json" \
  -d '{"test": true, "source": "manual-check"}' \
  -w "\nHTTP Status: %{http_code}\n"

# Verbose — see all request and response headers:
curl -v -X POST https://your-domain.com/webhook/your-path \
  -H "Content-Type: application/json" \
  -d '{"test": true}'

# Expected success response:
{"message":"Workflow was started"}
# Expected error response if still not registered:
{"message":"The requested webhook is not registered."}

Post-Fix Verification Checklist

• cURL returns {"message":"Workflow was started"} — not a 404.
• n8n Executions log (left sidebar → Executions) shows a new execution entry.
• The execution shows green checkmarks on all nodes — no red error nodes.
• Any downstream output (Telegram message, Google Sheets row, Slack ping) arrived as expected.
• Production URL configured in external app — not Test URL.

Frequently Asked Questions

Continue Learning on TriggerWorkflow