Workflow not getting triggered even after being in active state, Docker setup

krisn0x · September 23, 2025, 10:40pm

Thank you, that was key. There is an open issue for this being tracked:

Error with the public API of n8n when registering a webhook

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:

github.com/n8n-io/n8n

fix(core): Resolve Webhook registration for API-created workflows

master ← eric050828:fix/api-webhook-registration

opened 06:38AM - 17 May 25 UTC

eric050828

+410 -56

## 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.