n8n Webhook Node: How to Receive Data From Any Service

A webhook is the difference between a workflow that checks and a workflow that is told. Instead of polling a service every five minutes to see whether anything happened, you hand that service a URL and it calls you the moment something does.

In n8n that URL comes from the Webhook node, which sits at the very start of a workflow as its trigger. The node itself is simple. The parts that cost people time are the two URLs, the authentication choice, and deciding what the caller gets back, so this guide spends its time there.

What does the n8n Webhook node do?

It listens on a URL and starts your workflow when something calls it. n8n's documentation lists the HTTP methods it accepts: DELETE, GET, HEAD, PATCH, POST and PUT. Most integrations will send you a POST with a JSON body.

The Path parameter holds a randomly generated value by default, and you can replace it with something you choose. n8n also documents route parameters, so a path can carry variables in forms such as /:variable, /path/:variable, or /:variable1/:variable2. That is useful when one workflow should serve several related callers.

What is the difference between the test URL and the production URL?

They are two addresses for the same node, and they become active at different moments. n8n's documentation says the node displays both URLs at the top of the node panel, with a toggle to switch which one is shown.

The test URL is registered when you select Listen for Test Event, or when you execute the workflow while it is not active. Its whole purpose is visibility: n8n displays the incoming data right there in the editor, so you can see the exact shape of what the caller sent before you build anything against it.

The production URL is registered when the workflow is published. It does not display data in the editor, and n8n's documentation points you at the workflow's Executions tab to see what arrived. That is not a limitation, it is the point: a live webhook should not depend on anyone having the editor open.

Setting up a webhook, in order

1. Add the Webhook node as your trigger — It goes at the start of the workflow. Everything else hangs off it.
2. Choose the HTTP method — Match whatever the calling service sends. n8n supports DELETE, GET, HEAD, PATCH, POST and PUT.
3. Set the path, or keep the generated one — The default path is random, which is fine. Set your own when you want a readable URL or route parameters.
4. Listen for a real test event — Select Listen for Test Event, then have the real service fire, or send your own request. Look at the data that lands in the editor.
5. Build the rest of the workflow against real data — Now that you can see the actual payload shape, write your expressions against fields that genuinely exist.
6. Choose the authentication and response settings — Decide who is allowed to call this and what they get back. Both are covered below.
7. Publish, then test the production URL — Publishing is what registers the production endpoint. Send one real request and confirm it in the Executions tab.

That is a plain curl request, not anything n8n-specific, and it is the fastest way to prove an endpoint is reachable before you go looking for problems in the calling service. Send it once against the test URL and once against the production URL. If one works and the other does not, you have already found your answer.

How do you stop anyone from calling your webhook?

With the node's Authentication parameter, which n8n documents as offering Basic auth, Header auth, JWT auth, or None. A webhook URL is a public address, so None means anyone who learns the URL can start your workflow.

Header auth is the option most third-party services can actually use, since almost every integration lets you add a custom header to its outgoing calls. JWT auth is there when the caller already signs its requests. Basic auth works, and is best kept to internal callers you control.

n8n also documents an IP(s) Allowlist among the node's options, which is worth stacking on top of authentication when the caller has stable addresses. Two independent checks on an endpoint that can start automated work is not paranoia, it is proportionate.

What does the caller get back?

Whatever you choose in the Respond parameter, and the four documented options behave quite differently. This matters because some services will retry, or mark your endpoint unhealthy, if the response is not what they expect.

Pick Immediately when the caller only needs an acknowledgement and your workflow might take a while. Pick the Respond to Webhook node when the caller genuinely needs a result, because it lets you decide the exact moment and content of the reply rather than inheriting whatever the last node produced.

n8n additionally documents a Response Code parameter for choosing which HTTP status you send, and a Response Data setting offering All Entries, First Entry JSON, First Entry Binary, or No Response Body. If you are building against a service with strict expectations, those are the two dials to reach for.

Set-up work like this is exactly what we removed at Sistava. Rather than choosing a method, a path, an auth scheme and a response mode before anything useful happens, you hire an AI Employee and tell it in plain English what you want handled. It has the tools connected already, it asks you when it is unsure, and there is no endpoint for you to secure.

Which webhook options are actually worth knowing?

The Options section of the node is where several real problems get solved, and most people never open it. n8n documents the following among them.

• Allowed Origins (CORS). Needed the moment a browser rather than a server is calling your webhook.
• Raw Body. Gives you the untouched body, which is what signature verification schemes require.
• IP(s) Allowlist. Restricts which addresses may call the endpoint at all.
• Ignore Bots. Filters out crawler traffic that would otherwise start executions for no reason.
• Only Run If. An expression gate, so an execution only happens when the payload is one you care about.
• Response Headers and Response Content-Type. For callers that insist on a specific content type or expect particular headers back.
• Binary Property and Property Name. For handling file uploads arriving at the endpoint.

Only Run If and Ignore Bots deserve a second look if you are on a plan where executions are counted. Every request that reaches an unfiltered webhook is an execution, including the ones from scanners that found your URL by accident.

How big a payload can an n8n webhook accept?

n8n documents a maximum webhook payload size of 16MB, configurable on self-hosted instances through the N8N_PAYLOAD_SIZE_MAX environment variable. On managed hosting you work within whatever the platform sets.

If you are near that ceiling, the fix is usually design rather than configuration. Have the caller send a reference and let the workflow fetch the object, which keeps the request small, makes retries cheap, and avoids a failure mode that only appears on your largest and most important payloads.

What trips people up with n8n webhooks?

• Using the production URL on an unpublished workflow. n8n registers the production endpoint when the workflow is published. Before that, it is not there.
• Expecting the editor to show production traffic. It does not. The Executions tab is where live requests are visible.
• Leaving Authentication set to None. A URL is discoverable. Choose Header auth or JWT auth and add the IP allowlist where you can.
• Building expressions before seeing a real payload. Listen for Test Event first, then write your fields against data you have actually looked at.
• Ignoring the response contract. Some callers retry on anything that is not the reply they expect, which turns one event into many executions.

None of these are faults in n8n. The Webhook node exposes real HTTP honestly, including the parts that are fiddly, and that is the right call for a tool built for people who want control. The cost is simply that the contract is yours to define and yours to maintain when the other side changes.

If the reason you reached for a webhook was that something needed to happen when an event occurred, and not that you wanted to own an HTTP endpoint, that is the question Sistava answers. You hire an AI Employee, describe the trigger and the outcome in a sentence, and there is no path, auth scheme or response mode in between.

Sources

• n8n documentation, Webhook node
• n8n documentation, Respond to Webhook node
• n8n documentation, Build your first workflow
• n8n documentation, Use environment variables
• Synta, n8n Webhook Node tutorial