Question 1

Why does the Webhook node have separate test and production URLs?

Accepted Answer

Explain the mechanism, then name the mistake it causes in practice. "They are separate because building and production are two different modes. The test URL is registered only while you have pressed "Listen for test event" on the canvas, and it shows incoming data directly on the canvas — which is what you want while building. The production URL is registered when the workflow is published and does not show data on the canvas; you inspect it in the execution history. This is also the source of the most common mistake: someone hands the test URL to an external system, it works that day and stops the next. The reason is that the test listener was only armed at that moment. My rule is to publish the workflow and copy the production URL before giving any address to an external system."

Question 2

How do you prevent duplicates in events received by webhook?

Accepted Answer

Start by explaining where duplicates come from — that shows you understand the problem. "Duplicates arise for two main reasons: the caller received the response late and resent, or its delivery guarantee is at-least-once by design. I handle it at three levels: 1. Fast response — if processing is long I choose Respond: Immediately so the caller does not time out. That removes most duplicates at the root. 2. An idempotency key — I take the event's unique ID (usually in a header or the body) and check "have I already seen this?" before processing. I make the write an upsert where possible. 3. Storing processed IDs — a short-lived record in a Data Table or database. The underlying principle: a webhook receiver must be built idempotent, because the same event arriving twice is normal, not an anomaly."

Question 3

How do you secure a webhook that is exposed on the internet?

Accepted Answer

For a security question, speaking in layers is the strongest structure. "Layer one — authentication. The Webhook node supports basic, header and JWT auth. "None" is never acceptable on the open internet: a random URL is not a secret, because it ends up in logs, proxies and browser history. Layer two — signature verification. Many services (payment providers, GitHub and others) sign the body with a shared secret and send it in a header. Verifying that is stronger than authentication, because it confirms both the sender and that the content was not altered. Layer three — restricting access. Where possible I allow only the sender's IP range and block the rest. Layer four — treating the data as untrusted. I never put the incoming body straight into a database or a query; I validate the fields and coerce them to the expected types. There is also a payload size limit — on self-hosted it can be tuned through configuration."

Parameter	What it does	Practical note
Test URL / Production URL	Two separate addresses: one while building, one after publishing	The test URL only responds while "Listen for test event" is armed
HTTP Method	Which method it accepts	Check what the sender actually sends — a mismatch produces a 404
Path	The last part of the URL; randomly generated by default	Route parameters in the form `/:variable` are supported
Authentication	Basic auth, header auth, JWT auth or none	A webhook exposed on the open internet must require authentication
Respond	Immediately / when the last node finishes / via the Respond to Webhook node / streaming	Choose "immediately" for long processing so the caller does not time out
Response Code	The HTTP status code returned	Accepted but not yet processed → `202`

The Webhook node: receiving events and answering like an API

📚 Sources and documentation