I find myself using some 3rd party APIs that require to include dynamic elements into the URL. (i.e. /api/customer/{{id}}/update)
The same way, I really need to be able to create a webhook that can receive dynamic elements in the URL or even additional paths than the one set in the webhook. (defined by other systems in this way). (i.e this setup in n8n as the path: /webhook/invoice) and be able to receive posts to /webhook/invoice/{{id}}/delete or /webhook/invoice/{{id}}/update.
Maybe even a wildcard such as the ? works for query params that receives the post and brings the query param into the response. i.e /webhook/invoice?account=apj results in including this into the response: query: {“account”: “apl”}. This way anything after an ending “/” of the webhook could come to the response as additionalPath: “{{id}}/delete” or whatever comes after the defined webhook.
I really need this to go forward with a project, any ideas for a way around this would be awesome!
I think this can be a gamechanger in terms of the power of webhooks!
If you think this can help your projects please help me upvote this FR
Definitely see the value in a wildcard that then makes the rest of the URL available to the workflow. I imagine there are some complexities under the hood but would also allow to build out workflows that look and feel much more like RESTful endpoints (and so more usable with other systems). Have upvoted this.
Excellent!!! Thanks for the UpVote!
Regarding the query. I actually am receiving parameters and even without them being configures in the webhook url n8n processes these correctly!
The feature got yesterday merged and will be released with the next version. So not much longer. Is already available in the nightly docker build n8nio/n8n:nightly
This is awesome!!! @jan Tested, works just live video!
Now, one question. While running n8n cloud, I have a couple webhooks without the /{{webhookId}} in the url. This was one of the coolest features. When making any change to these webhooks it adds the {{webhookId}} so I will need to re-submit the endpoint to the 3rd party already running some workflows.
Is there any way to get rid of this {{webhookId}} in the URL as before?
Example below with 4 different incoming flows. Client create which does not have any {:id}, and then 3 more incoming commands that do have {:id} in the url regarding the specific customer id.
As you can see I had to manually include the {{webhookId}} in the path that does not contain {{:id}} in the url. vs the path in Update that does include an {{:id}} in the path.
TL;DR: if you want to use parameters in your route there is unfortunately no way around the usage of the {{webhookId}} as a prefix in the URL at the moment.
We thought a lot about possible solutions and their trade-offs, due to the many requirements such as scalability, reliability and flexibility. In the end we have to be able to identify what route we are receiving and how we need to parse it in order to pass the params with the right keys and values. We decided that prefixing the route with the webhookId would be the solution that provides the most flexibility and reliability with understanding that this solution might not be 100% optimal at times.
We will continue reiterating on this feature and improvements will be made in the future.
What could be added short-term is that the webhookId can also be transmitted via the body or the query in order to keep the route lean. Maybe this might be a solution for your cases?
@Ben, thanks for the reply and the great job with this feature! Adding {{webhookId}} to the body would not be a good thing because body usually comes in the way the 3rd party has defined the structure. (At least for our current use case)
Having the URL clean of long hashes was a nice thing, but I think it is really not a problem! We will send out our 3rd party the new URL structure including the {{webhookId} and this should solve it. I created this test scenario (posted above) with 4 incoming hooks (1 static and 3 dynamic) so what I did was add the original {{webhookId}} to the path on the static route since my 3rd party will only receive 1 endpoint and use it for all the 4 purposes (the static one and the dynamic ones).
Will keep you posted when we have this workflow up and running in production mode
@pradilla, awesome! Looking forward to hear what you have built and how it is running in production for you
as you have mentioned we wanted to keep the beauty of clean routes at least for static paths, however adding the {{webhookId}} to the static route(s) is what we recommend if you need to provide static as well as dynamic routes. So you are implementing it the same way as we would do it