A webhook is what turns an n8n workflow into a live HTTP endpoint — something Stripe, GitHub, a form on your website, or your own code can call to kick off automation instantly, instead of waiting on a scheduled poll. It's one of n8n's most useful features. It's also, by default, open to anyone who has the URL.
Two URLs, two very different purposes
Every Webhook node generates two distinct endpoints, and mixing them up is the single most common source of confusion:
- Test URL (contains
/webhook-test/) — only responds while the workflow is open in the editor and you've clicked "Listen for Test Events." Useful for building, not for production traffic. - Production URL — only live once the workflow is activated. This is the one external services actually call, continuously, whether or not anyone is watching the editor.
The node also supports multiple HTTP methods, configurable response timing (respond immediately, after the last node finishes, or via a dedicated Respond to Webhook node for full control over status codes), and a default 16MB payload size cap — adjustable via the N8N_PAYLOAD_SIZE_MAX environment variable on self-hosted instances.
Authentication: None is the default
Not a misconfiguration — the actual, documented default. A newly created Webhook node has no authentication requirement at all unless it's explicitly turned on. Anyone who discovers or guesses the URL can call it, inject arbitrary data, and trigger the workflow.
What's actually available, node by node
The Webhook node supports three real authentication methods, plus IP-level filtering as an additional layer — not a replacement for authentication:
- Header Auth. The caller must include a specific header name and secret value, defined as a credential. The standard choice for machine-to-machine calls and most SaaS platforms that let you set a custom header.
- JWT Auth. The caller sends a signed JSON Web Token; n8n verifies the signature (and optionally claims like expiry or issuer) using a passphrase or PEM key. The right choice when the calling system already issues JWTs — an identity provider, your own backend — since it avoids a manually rotated shared secret.
- Basic Auth. Username and password in the Authorization header. Works, but the credentials are only base64-encoded, not encrypted — it depends entirely on HTTPS to avoid interception, and is the weakest of the three.
- IP Whitelist. Restricts callers to specific source IPs or CIDR ranges — genuinely strong when the calling service publishes its IPs (Stripe does), but it's a network-layer filter, not authentication, and shouldn't stand in for one.
- Ignore Bots. Filters out crawlers, link-preview bots, and scanners that stumble across a webhook URL — worth enabling on every production webhook to avoid spurious executions eating into your run quota.
Why "turn on auth" isn't the whole answer
Authentication stops an attacker from triggering a workflow they shouldn't be able to. It doesn't validate that the payload came from who it claims to be from — that's what HMAC signature verification is for, on platforms that support it (GitHub and Stripe both sign their webhook payloads). It doesn't cap resource usage from a legitimate-looking but abusive caller — that's what payload size limits and rate limiting are for. Real webhook security is layered, not a single setting to enable once and forget.
See the platform
n8n for Business, with webhook infrastructure managed and secured as part of the platform — not left to you to configure correctly.
Explore n8n for Business