Flexible Webhook Endpoints

[solomon]

The Problem

Currently, creating RESTful APIs with n8n is cumbersome because the webhook node does not support optional paths or dynamic route configurations. For example, if you want an endpoint like /user/:id/file/:id, you need to create individual webhook nodes for every possible variation of that path, such as:

• /user
• /user/:id
• /user/:id/file
• /user/:id/file/:id

Additionally, you must multiply this by the number of HTTP methods (GET, POST, PUT, DELETE, PATCH, etc.), which can result in 30+ webhook nodes just for basic functionality.

This approach makes workflows unnecessarily complex and harder to maintain.

---

The Use Case

I’m building the backend of an MVP using n8n and Supabase, and we plan to stick with n8n for processing all data, even as we scale. To make this feasible, I need a way to define REST API endpoints with greater flexibility and fewer nodes, following REST API best practices.

For example, I should be able to configure a single webhook node that handles:

• /user/:id (optional id)
• /user/:id/file
• /user/:id/file/:fileId

This would drastically reduce the complexity of workflows and align n8n with modern API design standards.

---

Why This Is Beneficial

1. Simplifies Workflows: Reduces the number of webhook nodes required, making workflows easier to create and maintain.
2. Improves Scalability: Allows developers to build more complex APIs without creating an unmanageable number of nodes.
3. Aligns with Standards: Supports REST API best practices, improving interoperability and readability for developers.

---

Supporting Resources

• Optional Endpoint path in webhooks - is it possible?
• Best Practices for REST API Design – Stack Overflow Blog
• RESTful API Design Best Practices Guide 2024

---

Willing to Contribute

Yes

---

If you like this idea, don’t forget to upvote! The more votes this feature gets, the higher its priority will be.

[liam]

I have been planning to request this and i am also willing to contribute to this feature.

I would also like to add the following items/context:

Dynamic Methods

It seems really limiting that we can only have a webhook accept one http method. Whenever i am making something in a style of an API, which is generally the style i like to use, i like to have a “router” workflow that catches the workflow and routes it to subworkflows.

This convention works really well for me because it lets me add “middle ware”, essentially logic that runs before the workflows to do preverification, security checks, or any other logic that would be good to run before sending the data off to get processed by the sub workflow.

Having dynamic methods would allow me to have multiple methods in one workflow instead of having a seperate “router” workflow for each method.
This would let you use an if or switch node to check if the method is post or delete and route to the needed subworkflows

Here is a practical example of one of our “router” workflows. This is from zoom and you can see it allows us to add teh token challenge once instead of for each workflow that needs to catch a zoom hook.

Defining “Wildcards” in the path

Having a dynamic path is a great idea.

While those used to developement are very familier with the /user/:id/file/:fileId style for dynamic paths, for n8n it could stay consistant with what the users are used to like /user/{{ id }}/file/{{ fileId}} .
Then the webhook can save those fields to the id and fieldId keys in the json to be used in the workflow.

Another Possible Dynamic Path implementation

Something else that might have even more flexibility is if n8n passes everything after the first / as a param.

so if your webhook is like this:
`yourUrl.com/webhook/user/id

then n8n still routes everything to the path yourUrl.com/webhook/user and passes id as a parameter.

This would likely be easier to impliment and would have more flexibility for the user.

Example Workflow using this feature

Here is a very rough example of how i would use this feature to impliment a “router” workflow

i had to put a screenshot instead of embedding because of char limits in comments

@solomon I don’t mean to step on your feature request! Just wanted to add to it. I would be curious to hear your feedback on my thoughts.

[solomon]

That’s awesome! Apparently you have great experience with using n8n for API-like features.

[octionic]

@liam, multiple methods can be enabled in the settings tab of the webhook node. Would that solve your issue?

[liam]

How did I not know that???
I’ll try that out today

[octionic]

I guess it’s because you don’t follow the Unofficial n8n Spotlight on Youtube yet
It’s really a pity that this important feature is hidden away.

[liam]

Yeah their settings tab needs some love. I see a lot of people not even knowing it exists

[Hannes_Lehmann]

I came up with a custom node, but still struggeling with how n8n internally listens to endpoints. So it’s not functional.

[liam]

Do you have the GitHub link?

Maybe I’ll submit a pr with the functionality if that’s fine with you

[Hannes_Lehmann]

Not yet, but can setup soon and paste it here

[Ruslan_Yanyshyn]

@octionic

Unofficial n8n Spotlight

Thank you, @octionic, for sharing the channel! It’s a great resource, but it was quite difficult to locate. It would be helpful if it could be featured on the official n8n website or forum.

[solomon]

To anyone interested in this:
I’ve come up with a workaround for the API path.

First I leave the URL open to any endpoint, instead of using one webhook for each endpoint:

Then I use a path parameter to determine the endpoint:

Finally I extract the HTTP method and the endpoint, to route it to the appropriate subworkflow:

I would love a better solution that could use the path in the URL itself, instead of using a query parameter.

But this works well too.

@octionic @liam @Hannes_Lehmann