Understanding and Securing Webhooks

A webhook is essentially an open door into your n8n system: as soon as an external service sends an HTTP request to the URL generated by the Webhook node, the associated workflow starts automatically, with no schedule and no manual click. This exact openness is what makes webhooks so useful for integrations with Stripe, GitHub, form tools, or your own applications. But it also turns the URL into a point of attack if no authentication, no IP filter, and no signature check stand in the way. Anyone who knows or guesses the URL can trigger the workflow.

This article shows the structure of the Webhook node in n8n, the built-in authentication methods, IP whitelisting as an additional protection layer, and the configuration behind a reverse proxy, a point that regularly causes confusion with self-hosted n8n instances. As of: July 2026.

How the Webhook node is structured

According to the n8n documentation on the Webhook node, the node supports six HTTP methods: DELETE, GET, HEAD, PATCH, POST, and PUT. In the Path field you set the path of the URL, either freely or with placeholders like /:variable for dynamic segments. Without your own input, n8n generates a random path, which avoids collisions with other workflows.

There are several options for the response:

• Immediately: The webhook responds immediately with the message that the workflow has started, without waiting for it to finish.
• When Last Node Finishes: The response contains the data of the last node executed.
• Using Respond to Webhook Node: A dedicated node in the workflow specifically controls the status code, headers, and body of the response.
• Streaming response: For nodes with streaming support, the response can be transmitted in real time.

Important in practice: according to the documentation, n8n only registers one combination of path and HTTP method at a time. Two active workflows with the same path and the same method block each other; one must be deactivated, or the path or method changed.

Authentication directly in the Webhook node

Before you think about IP filters or reverse proxy rules, you should use the built-in authentication of the Webhook node. According to the documentation on webhook credentials there are four options to choose from:

• Basic Auth: The calling service must send a username and password in the Authorization header. Easy to set up, but only sensible in combination with HTTPS since it offers no additional encryption.
• Header Auth: You define a header name, for example X-API-Key, and a secret value. n8n checks every incoming request for exactly this header. This method fits well with services that already send an API key.
• JWT Auth: The request must contain a digitally signed JSON Web Token. n8n verifies the signature via a passphrase or a PEM key that you store in the credential.
• None: No check, every request with the correct path is accepted. This setting is suitable at most for brief tests, not for production workflows.

The documentation makes an important point clear here: the chosen method must match what the calling service actually sends. A GitHub webhook, for example, typically signs requests via an HMAC signature in the header, which you can additionally check in a Code node beyond the header auth, if you want to secure things beyond pure node authentication.

IP whitelisting as an additional protection layer

In addition to authentication, the Webhook node offers the IP(s) Whitelist option. There you enter a comma-separated list of allowed IP addresses; according to the documentation, n8n responds to requests from addresses not on the list with a 403 error. If the field is left empty, all addresses are allowed.

In practice, IP whitelisting works best as a second layer alongside Header Auth or JWT Auth, not as the sole protection: if a service like Stripe or GitHub has fixed sender IP ranges, you enter them and block everything else by default. For services with changing or unclear IP ranges, header or JWT verification remains the more reliable method. This way you keep control over who can even reach the workflow before the actual logic starts running.

Configuring webhooks behind a reverse proxy correctly

If n8n is self-hosted behind a reverse proxy, for example Caddy, Nginx, or Traefik, automatic URL detection no longer works reliably: n8n usually runs internally on port 5678, while the proxy exposes the application externally via port 443. According to the n8n documentation on webhook URL configuration behind a reverse proxy you solve this with two environment variables:

• WEBHOOK_URL: Sets the full, publicly reachable address that n8n displays in the editor and registers with external services, for example https://n8n.example.com/.
• N8N_PROXY_HOPS: Must be set to the number of upstream proxies, usually 1. This allows n8n to correctly interpret the headers forwarded by a proxy.

The proxy itself must pass through the headers X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto. If this configuration is missing, the IP whitelisting from the previous section can end up having no effect, because n8n then only sees the internal proxy address instead of the actual sender IP. According to n8n documentation, this exact connection is one of the most common sources of error: whitelisted IPs are rejected even though the list is correctly maintained, because N8N_PROXY_HOPS is missing or set incorrectly.

Not confusing the test and production URLs

Every Webhook node generates two different URLs. The test URL displays incoming data in the editor as soon as you click Listen for Test Event in the node, but according to the documentation it stays active for only 120 seconds. The production URL only takes effect once the workflow is published, but then no longer shows data in the editor, only in the Executions tab.

A typical mistake in practice: an external service is configured to use the test URL during development, because it provides visible feedback in the editor. After the workflow is published, the webhook then goes nowhere, because the service still addresses the old test URL instead of the production URL. So before every go-live, check whether the production URL is actually stored in the calling system. Anyone who uses n8n as a self-hosted digital employee and values clean, traceable webhook security will find in the n8n consulting from NordFlux support with setup, authentication, and reverse proxy configuration.

Frequently asked questions

Is Header Auth alone enough to secure a webhook?

For many internal automations, Header Auth over HTTPS is sufficient, as long as the secret value is long enough and not guessable. For security-critical integrations, for example payment providers, additional IP whitelisting or a signature check like HMAC in a downstream Code node is recommended.

Why is my whitelisted IP address still blocked?

This is usually due to a missing or incorrectly set N8N_PROXY_HOPS when n8n runs behind a reverse proxy. Without this variable, n8n does not see the actual sender IP but the internal address of the proxy, and incorrectly compares this to the whitelist.

Can I put several workflows on the same webhook path?

No, according to n8n documentation, only one webhook can be registered per combination of path and HTTP method at a time. For multiple triggers on the same path, you must use different HTTP methods or adjust the path.

What happens if I keep using the test URL after development?

The test URL is only active for 120 seconds after clicking Listen for Test Event and displays data in the editor. After the workflow is published, calling systems must be switched to the production URL, otherwise their requests go nowhere.

Do I have to use JWT Auth if the calling service does not offer it?

No, the authentication method always depends on what the calling service actually supports. If a service only offers a simple API key, Header Auth fits better than JWT Auth, which requires a signed token.