Hi community,
I’m running n8n 1.111.0 self-hosted on an AWS EC2 instance with Postgres as the database (via Docker).
The issue
When I create a workflow (either via UI or API) and mark it as active:
It appears active in the UI.
But when I hit the production webhook URL, I always get:
{
“code”: 404,
“message”: “The requested webhook "POST " is not registered.”
}
What I tried
On my local Docker setup, everything works fine (workflows register, webhooks trigger).
On EC2, no workflow (UI-created or API-created) ever registers.
Tried with both API key and session cookie for API requests.
Env vars include:
N8N_USER_MANAGEMENT_DISABLED=false
N8N_SECURE_COOKIE=false
NODE_ENV=production
Question
Why would workflows show as active but never actually register webhooks in runtime?
Could this be related to environment variables, queue mode, or something else?
krisn0x
September 23, 2025, 9:59pm
2
Hey, can you post your full list of env variables?
Hey, sure @krisn0x
Sharing the entire docker file with you.
version: “3.8”
services:
postgres:
image: postgres:14
restart: unless-stopped
environment:
- POSTGRES_USER=n8n
- POSTGRES_PASSWORD=n8n
volumes:
- postgres_data:/var/lib/postgresql/data
- ./init.sql:/docker-entrypoint-initdb.d/init.sql
ports:
- "5432:5432"
networks:
- internal
n8n-dev:
image: n8nio/n8n:1.111.0
restart: unless-stopped
environment:
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n_dev
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=n8n
- N8N_BASIC_AUTH_ACTIVE=true
- N8N_BASIC_AUTH_USER=dev
- N8N_BASIC_AUTH_PASSWORD=dev123
- N8N_HOST=0.0.0.0
- N8N_PORT=5678
- N8N_PROTOCOL=http
- WEBHOOK_URL=http://dev.n8n.local:5678/
- N8N_SECURE_COOKIE=false
- N8N_USER_MANAGEMENT_DISABLED=true # 👈 disables teams/users, makes API mode work like local
- N8N_API_KEY=supersecretapikey # 👈 backend uses this to create/activate workflows
ports:
- "5678:5678"
depends_on:
- postgres
networks:
- internal
n8n-prod:
image: n8nio/n8n:1.111.0
restart: unless-stopped
environment:
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n_prod
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=n8n
- N8N_BASIC_AUTH_ACTIVE=true
- N8N_BASIC_AUTH_USER=admin
- N8N_BASIC_AUTH_PASSWORD=admin123
- N8N_HOST=0.0.0.0
- N8N_PORT=5679
- N8N_PROTOCOL=http
- WEBHOOK_URL=http://prod.n8n.local:5679/
- N8N_SECURE_COOKIE=false
- N8N_USER_MANAGEMENT_DISABLED=true # 👈 same here
- N8N_API_KEY=anothersecretapikey # 👈 separate prod key
ports:
- "5679:5679"
depends_on:
- postgres
networks:
- internal
volumes:
postgres_data:
networks:
internal:
driver: bridge
Also @krisn0x sharing one more important thing.
If I go to the UI of my n8n docker instance, do some really small changes in the workflow which I have created via API, after that the production url starts working.
It feels like the active value is being updated in db thus I am seeing that in UI, but at some place it is being missed when I trigger the API from postman/backend service.
krisn0x
September 23, 2025, 10:40pm
5
Thank you, that was key. There is an open issue for this being tracked:
opened 05:29PM - 29 Mar 25 UTC
in linear
Needs Feedback
team:nodes
### Bug Description
I'm generating a workflow using the public API of n8n. With… in it, I include a webhook. Once the webhook is activated, I get the path to run the automation, but the webhook does not respond. I enter the automation and activate the test mode, and it works perfectly. Then, I want to use the production mode, and it doesn't work. I realized that just by entering the flow manually, making a minimal change, and pressing the save button, it starts working. I tried to make a PUT request to modify something minimal, but it didn't work. I also tried to activate and deactivate the flow from the API, and that didn't work either. The only thing that works is entering the flow and saving it again manually, but I need to do this automatically, not manually.
### To Reproduce
1 generate the call to the API to create the workflow.
2 With the flow ID, I look for all the nodes.
3 obtain the ID of the webhook.
4 make a PUT request to modify the path of the webhook with the new ID that I generated.
5 activate the workflow.
6 obtain the complete URL of the webhook.
7 use the webhook URL, and it does not respond.
8 manually enter and make a modification to anything in the flow.
The "save" button becomes enabled.
9 press the save button, and the webhook in production starts working.
### Expected behavior
What should happen is that when activating the workflow, the webhook should register automatically to avoid any manual processes.
### Operating System
ubuntu 22.04
### n8n Version
1.84.3
### Node.js Version
18.16
### Database
PostgreSQL
### Execution mode
main (default)
Please drop a comment there.
There’s also a PR in the works it seems:
master ← eric050828:fix/api-webhook-registration
opened 06:38AM - 17 May 25 UTC
## Summary
This PR addresses a critical issue where Webhook nodes within work… flows created and activated via the n8n API failed to correctly register their production Webhook URLs. This misregistration led to `404 Not Found` or `500 Internal Server Error` responses when attempting to trigger these webhooks. Additionally, the n8n UI would display a randomly generated UUID path for these webhooks until the workflow was manually saved.
The core of the fix involves ensuring the correct initialization, setting, and persistence of essential webhook parameters (`parameters.path` and `node.webhookId`) to the database during workflow activation. This is achieved through:
1. **Enhanced `active-workflow-manager.ts` logic**:
* Ensuring `node.webhookId` and `node.parameters.path` are set (typically to `node.id`) if not already defined for webhook nodes.
* Implementing reliable state comparison using `lodash.cloneDeep` before saving workflow entities to accurately detect changes in node parameters and `webhookId`.
* Correctly flagging `workflow.staticData.nodesParametersChanged = true` when modifications occur, forcing a database update.
* Applying `lodash.cloneDeep` when loading workflow data (`nodes`, `connections`, `staticData`, `settings`) to prevent unintended modifications to cached entities and ensure accurate comparisons.
* More immediate calls to `webhookService.populateCache()` after webhook data is stored and relevant database entities are updated to ensure cache coherency.
2. **Standardized Webhook Path Handling**:
* Refined `getNodeWebhookPath` in `n8n/packages/workflow/src/NodeHelpers.ts` to consistently generate webhook paths, primarily based on `node.webhookId` (which is set to `node.id`).
* Corrected path comparison logic in `executeWebhook` within `n8n/packages/cli/src/webhooks/live-webhooks.ts` by normalizing paths (e.g., removing trailing slashes) before comparison to reliably match incoming requests to stored `IWebhookData`.
These changes ensure that webhook URLs are generated predictably, persisted correctly, and looked up reliably, resolving the 404/500 errors.
**How to Test:**
1. **Manual API cURL/Postman Test**:
* Using the API, create a simple workflow containing a Webhook node (e.g., named "WebhookTrigger", HTTP method GET) followed by another node (e.g., NoOp).
* Activate this workflow via the API.
* Retrieve the workflow details via API to find the Webhook node's `id`.
* Construct the production Webhook URL. According to the corrected logic, this should typically be `YOUR_N8N_URL/webhook/NODE_ID` (e.g., `http://localhost:5678/webhook/abcdef123456` if `NODE_ID` is `abcdef123456`).
* Send a GET request to this constructed URL using `curl` or Postman.
* **Expected Result**: A `200 OK` response (or the response configured in the NoOp node if the Webhook node's `responseMode` is set to wait for downstream execution). No 404 or 500 errors should occur.
2. **n8n UI Verification**:
* Open the n8n UI and navigate to the workflow that was created and activated via the API in the previous step.
* Inspect the Webhook node. The "Production URL" displayed in the UI should now consistently match the path based on the node's ID (e.g., `YOUR_N8N_URL/webhook/NODE_ID`), not a random UUID.
## Related Linear tickets, Github issues, and Community forum posts
* fixes #5681
* fixes #14267
## Review / Merge checklist
- [X] PR title and summary are descriptive. ([conventions](../blob/master/.github/pull_request_title_conventions.md))
- [ ] [Docs updated](https://github.com/n8n-io/n8n-docs) or follow-up ticket created.
- [X] Tests included.
- [ ] PR Labeled with `release/backport` (if the PR is an urgent fix that needs to be backported)
Not sure if this affects everyone or not, will have to test myself (tomorrow) and report back.
For now, I will appreciate if you mark this as Solution, it will not close the thread.
krisn0x
September 26, 2025, 1:21pm
6
Hey, just checking with one more idea: if you haven’t checked, can you please ensure all workers are on the same version as your main instance and redeploy them if not?
system
Closed
December 25, 2025, 1:22pm
7
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.