Expose HTTP Method in Webhook Response Headers

Feature Requests Nodes
,
1

It would help if there was a node for:
Exposing the incoming HTTP method (GET, POST, PUT, PATCH, DELETE) in the Webhook node output and/or response headers (e.g. request.method and/or x-http-method).

My use case:
I use the Webhook node as an API entry point where a single endpoint handles multiple HTTP methods, similar to REST routing.

Typical pattern:

  • GET → read data

  • POST → create or confirm a resource

  • PUT / PATCH → update

  • DELETE → remove

In this context, the HTTP method is a first-class routing signal. Currently, implementing method-based logic in n8n requires workarounds and makes workflows harder to read, reason about, and maintain.

If the HTTP method were explicitly available (for example as request.method in the node output, or as a response header like x-http-method), it would enable:

  • Clear and explicit routing logic

  • Cleaner API-style workflows

  • Fewer hacks and assumptions

  • Better maintainability for complex webhook-based APIs

Any resources to support this?

  • REST API best practices rely on HTTP methods as the primary routing mechanism.

  • Most backend frameworks (Express, Fastify, Laravel, Django, etc.) expose the HTTP method by default for routing and middleware.

  • n8n is increasingly used to build API and API-adjacent workflows where this pattern is standard.

2

Hey @Ocade_Fusion,

One thing you could do is use a Set node after your Webhook node and add something like {{ $(‘Webhook’).params.httpMethod[$prevNode.outputIndex] }} what this will do is get the httpMethod array from the node then use the outputIndex to select it. By using this approach it will also automatically update itself no matter which order you have the methods in and it will just append it nicely to your existing data, I typically use it meta.method

1 Like
4

HTTP method should be first-class. Today n8n does receive it, but it’s not surfaced cleanly. The workaround is to extract method from the Webhook node and route on it yourself.

What works reliably right now:
• Use a Code node immediately after Webhook → return { method: $json.method }
• Then use a Switch node on method (GET / POST / PUT / PATCH / DELETE)
• Optional: support x-http-method-override via headers for REST-style clients

It’s doable, but agreed: native exposure in the Webhook output would massively improve readability and API-style workflows. Solid feature request.

If you want, I can show you a clean REST-style webhook pattern I use in production:

5

Thanks :slight_smile:
Possible with settings node switch.