Keep webhook URL on import

Context:
We have n8n deployed to multiple remote (no internet) locations. We create n8n workflows with webhook triggers locally and like to deploy them to the remote locations.

Problem:
The problem is that each remote location will have a different n8n webhook url after import of the workflow. So we need to specify a different webhook endpoint url in every app. We would like to copy/transfer a n8n workflow with a static webhook url.

Example:
http://n8n.[location].com/webhook/STATIC

Proposals:

  • Keep the webhook url on import if it is not in use
  • Let the user create named webhook urls if he likes to keep the url consistent across instances

I can see how that could be helpful and needed for some use-cases.

That would mean however that it would have to work totally different and incompatible with the current way. As right now the workflow-id is part of the webhook-URL.
So one way to make that work would be to add some kind of “Webhook URL Mode” that people can set the “full” webhook path (so everything past “webhoook/”). The default would be the old behavior (so nothing would break) and people could optionally set it to the other “mode” if needed.

2 Likes

We just released a beta version of n8n with static webhooks. For existing webhook-nodes it will keep on working like before. Meaning the webhook-URL is a combination of workflow-id and webhook-name. For newly created nodes it will by default create a UUID. The value can simply get changed. It is however important to mention that webhook-URLs are now unique so not two different workflows could define the path GET /webhook only one can. If two define the same and both workflows gets set to active at the same time, it will error and will not allow the second one to get activated.

The beta image: n8nio/n8n:0.70.0-static-webhooks-beta

Please inform us if everything new and existing works fine that we can release it asap. We did already test but the more people the better obviously.Thanks!

1 Like