Webhooks in N8N: A Practical Guide to Receiving Data

Almost every useful automation starts with an event: a form submitted, a payment approved, a message received. For N8N to react to these events the moment they happen, the most common path is a webhook. In this guide, we'll look at how it works, how to set it up securely and which precautions save you headaches in production.

What is a webhook?

A webhook is an HTTP address that waits to be called. Instead of N8N asking a system every few minutes whether there's anything new, the system itself notifies N8N as soon as the event happens, sending the data in a request.

This inversion brings two clear advantages: the automation reacts within seconds, and no resources are spent on queries that find nothing.

Approach	How it works	When to use
Polling	N8N queries the system at fixed intervals	The source system doesn't offer webhooks
Webhook	The system calls N8N when the event happens	Whenever the source allows it

How the Webhook node works in N8N

The Webhook node is a trigger. When you add it as the first node of a workflow, N8N generates a unique address for that workflow. Each request received at that address starts an execution, and the request body, headers and parameters become available to the following nodes.

The node's main options are:

• HTTP method: GET, POST, PUT, PATCH, DELETE or HEAD. Most integrations send POST.
• Path: the end of the address. A readable path, such as store-orders, makes maintenance easier.
• Authentication: none, Basic Auth, Header Auth or JWT.
• Response: when and what to send back to the caller.

Test URL and production URL

This is the point that confuses beginners the most. Each Webhook node has two addresses.

The test URL only works while you click listen for test event in the editor. It receives a single call and shows the data on screen, which is great for building the workflow with real data.

The production URL only responds when the workflow is active. This is the one to register in the source system. If the system is configured with the test URL, calls will fail as soon as you close the editor.

A simple rule avoids the problem: use the test URL while building and switch to the production URL before activating the workflow.

Protecting your webhook

A webhook is a public address. Anyone who discovers the URL can call it, so it's worth adding at least one layer of protection.

Header authentication

The Header Auth option requires the request to carry a header with a secret value. It's the simplest approach and works with almost every system that lets you set custom headers.

Signature verification

Payment and messaging platforms usually sign each request with a shared secret. In that case, validate the signature right at the start of the workflow, with a Code or Crypto node, and stop the execution if it doesn't match.

Other precautions

• Always use HTTPS. Data travels encrypted and the address isn't exposed on the network.
• Avoid obvious paths. A random path doesn't replace authentication, but it reduces unwanted calls.
• Validate the incoming data. Check that the expected fields exist before saving anything.
• Limit the size. N8N rejects bodies above the limit set in N8N_PAYLOAD_SIZE_MAX, which defaults to 16 MB.

Responding to the caller

Every webhook returns an HTTP response. N8N offers three modes:

1. Immediately: returns a 200 code as soon as the call arrives, before running the workflow. Ideal when the source only needs to know the event arrived.
2. When the last node finishes: waits for the workflow to end and returns the last node's data. Useful for short workflows that calculate something.
3. Using the Respond to Webhook node: you decide at which point of the workflow to respond and what to send, including status code and headers.

Many systems give up on the call after a few seconds and try again. If your workflow is long, respond immediately and process afterwards. This prevents duplicate executions caused by retries from the source.

Dealing with duplicate calls

Even with a fast response, the source may resend the same event. To keep this from creating duplicate orders or charges, treat each event as something that may arrive more than once.

The most common technique is to store the ID of each processed event and check, at the start of the workflow, whether it has already been seen. If it has, the execution ends with no effect. Systems like this are called idempotent.

Example: a new online store order

Picture a store that needs to notify the team and record every approved order:

1. The store platform calls the production webhook with the order data.
2. The workflow validates the secret header and responds immediately.
3. An IF node checks whether the status is approved.
4. The order is saved to a spreadsheet or database.
5. The team receives a message with the order summary.

This workflow takes a few minutes to build and replaces manually checking orders throughout the day.

Webhooks need an instance that is always up

A webhook only works if N8N is available at the moment the event happens. If the instance is down, the call fails and, depending on the source, the event is lost.

That's why anyone who depends on webhooks needs a stable instance, with HTTPS configured and a fixed address. With lui, each customer has a dedicated N8N instance with its own address and HTTPS, ready to receive webhooks from day one.

Conclusion

Webhooks are the fastest and most efficient way to connect N8N to the systems you already use. Remember to use the production URL, protect the endpoint, respond quickly and handle duplicate events. With these precautions, your automations react within seconds and securely.