n8n Webhooks: Setup and Why Yours Is Not Firing

“The webhook is not arriving” is the most common n8n question. The good news: the causes are finite and check out in a few minutes.

Test versus production URL

This is the source of most confusion, so it goes first.

The test URL lives only while you have pressed listen in the editor. It waits for one request, shows what arrived, and goes quiet. It is a debugging tool: convenient for seeing once what a service actually sends.

The production URL works continuously but only on an active workflow. Not activated, and the address returns an error.

The practical consequence: an integration pointed at the test URL stops working the moment you close the editor. Going live is not only flipping the toggle but also changing the URL on the caller side.

Why it does not arrive: the checklist

Work top to bottom; it is faster than guessing.

1. Is the workflow active? Cause number one.
2. Is it the right URL? Test instead of production is cause number two.
3. Does n8n know its public address? With the public URL variable unset, the interface shows localhost, which no external service can reach. See installing n8n.
4. Is there HTTPS? Many services refuse to send webhooks over plain http.
5. Does the method match? The node expects POST, the service sends GET, and nothing handles it.
6. Does the path match? A trailing slash or an edited path in the node produces a 404.
7. Is a proxy cutting it off? An aggressive timeout or body size limit on the reverse proxy drops the request before n8n.
8. Is the sender sending at all? Check their logs: often the webhook is disabled or the address was saved wrong.

The most useful check: send a plain curl request to the production URL. If an execution appears in the history, n8n is fine and the problem is the sender. If not, it is the network, the address or activation.

Responding to the caller

By default the webhook responds immediately without waiting for the workflow to finish. That is right in most cases: the sender gets an acknowledgement and does not hang.

Sometimes you need to return the result - when you are building an API endpoint, for instance. Then the response mode returns data from a chosen node, and a constraint appears: the caller waits. If the workflow takes half a minute, the sender holds the connection for half a minute, and their own timeout may fire before your answer.

The working rule: for long processing, acknowledge immediately and deliver the result separately - by callback, message or database write.

Separately: the status code matters. Many services retry delivery on an unsuccessful code. Answering with an error to a request you accepted correctly earns you copies of it.

Protecting the endpoint

A webhook is a public address on the internet, and it will be found: scanners walk paths constantly.

The minimum set:

• A secret in the request. A header or token checked by the very first node. No match, execution stops.
• Signature verification, when the service provides it. More reliable than a token because it also validates the content.
• Nothing happens before validation. The check comes before any action on the outside world.
• A body size limit on the reverse proxy.

And an important one: a long random path is not protection. It is not a secret, it is an address; it leaks into logs, browser history and the settings of the service that calls it.

Duplicates and retries

A topic people meet late: the caller may send the same webhook twice. That is normal retry behaviour, not a fault.

Hence the requirement that processing be safe to repeat. Check the event identifier and skip what you already handled, or you get two orders, two emails and two charges.

Trigger mechanics in general: triggers and webhooks. Parsing the payload: JSON in n8n. The overview is in the n8n guide.