Webhook by name

[mvhirsch]

Hey there. I’ really n8n!
I was recently playing around with the incoming webhooks feature which is really easy to use (until you saw the tutorial). But for development/production I’m not really sure how to use this.

Imagine 20 webhooks registered in production, you just hardcoded within various microservices. They all need to know that specific ID. Is there a way to name those webhooks, so my microservices should not be aware of any increasing ID by n8n?

I’d rather prefer using URLs like: http://n8n.example/webhook/my-workflow/webhook/new-input
Is there any way to easily develop locally and prepare any endpoints for my services, without even knowing the final ID?

Greets from Austria,
Michael

[jan]

welcome to the community @mvhirsch and very great to hear that you love n8n!

About your question. It sounds it would require the same as what is needed for this one:

Keep webhook URL on import [GOT CREATED]

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 Proposa…

That is sadly currently not possible. A webhook-URL is unique for every workflow and you can not simply point it to a totally different one. I can definitely see how that can be needed and it will probably be possible in the future but have sadly no estimate. That depends on how much development resources are available and how many people are requesting this feature.

In the meantime, it is probably best to handle that externally with something like Nginx or:

Most Trusted Open Source API Gateway | Kong Gateway

You can create your webhook endpoints in Kong and then dynamically change them if you need them to point to another workflow. Sorry, I can right now not think of another good temporary solution.

[mvhirsch]

Thanks for answering, @jan.
The workaround you’re suggesting is the one I actually thought of, too (using nginx instead of Kong).