The Webhook node (n8n-nodes-base.webhook) is n8n’s primary inbound HTTP
receiver, exposing a unique URL that external services call to trigger
workflows. It supports six HTTP methods, four built‑in authentication
modes, four response modes, and a 16 MB payload ceiling. The node
generates two distinct URLs—a Test URL for development
and a Production URL that activates on publish—and passes
the full request body, headers, query parameters, and route params as
workflow input[reference:0][reference:1].

How do you configure HTTP methods and multiple methods on the n8n Webhook node?

The Webhook node supports six HTTP methods: DELETE, GET, HEAD, PATCH,
POST, and PUT. By default it listens for a single method selected from
the HTTP Method dropdown. Enable Allow Multiple
HTTP Methods in the node’s Settings to accept several methods at
once—defaulting to GET and POST—which creates separate output branches for
each, enabling method‑specific downstream logic like GET for parameter
reads and POST for payload processing[reference:15].

When multi‑method mode is active, a Switch or IF node downstream can
inspect the {{ $json.method }} field to route POST
payloads versus GET parameter requests. The Path parameter
supports dynamic route segments using colon‑prefixed syntax (e.g.,
/:userId, /users/:id), and
$('Webhook').params.<parameterName> retrieves them
in expressions. n8n enforces one webhook per unique path‑method combination
to prevent routing ambiguity[reference:16]. The Test URL is available
immediately after you add the node; the Production URL only becomes active
once you publish (activate) the workflow. For a complete walkthrough of
multi‑method patterns with response handling, see our
n8n trigger nodes guide.

How do you secure the Webhook node with Basic Auth, Header Auth, and JWT?

The Webhook node provides four built‑in authentication methods selectable
from the Authentication dropdown: Basic Auth
for username‑password pairs sent in the standard Authorization header as
Base64‑encoded credentials; Header Auth for custom
header‑name‑and‑value checks ideal for API key scenarios;
JWT Auth for bearer‑token validation; and None
for public endpoints. All methods verify who is calling
but do not verify payload integrity—a Header‑Auth‑protected
webhook still accepts a tampered body[reference:17].

For defense‑in‑depth, layer built‑in authentication with HMAC payload
signing (see H2 5) and IP allowlisting (see H2 6). The community
@prokodo/n8n-nodes-secure-webhook node bundles all of
these layers—HMAC/JWT auth, API key verification, replay protection,
IP allow/deny policies (CIDR), per‑IP rate limiting, and Redis‑backed
HA state—into a single hardened trigger. It supports raw‑body or extended
HMAC signatures (method + path + query + timestamp + nonce + bodyhash)
and provides external audit export of accept/reject metadata[reference:18][reference:19].
For the complete credential‑level security model across all node types, see
the node security guide.

How do Webhook response modes control what the caller receives?

The Webhook node provides four response modes that control when and how the
HTTP response is sent. Immediately (onReceived) returns a
200 status with a simple “Workflow started” message the instant the webhook
fires, before any downstream nodes run—best for fire‑and‑forget scenarios.
When Last Node Finishes (lastNode) executes the entire
workflow and returns the last node’s output with a configurable status
code[reference:20].

Using ‘Respond to Webhook’ Node (responseNode) delegates
full response control to a dedicated Respond to Webhook node anywhere in
the workflow. This node supports custom status codes, response headers,
and body content. A critical caveat: if the workflow finishes without
executing a Respond to Webhook node, the caller receives a standard 200
message; if an error occurs before the first Respond to Webhook executes,
a 500 status is returned[reference:21]. Streaming mode sets
up chunked transfer encoding on the HTTP response, useful for real‑time data
transmission from streaming‑capable nodes like the AI Agent[reference:22].
For production, use When Last Node Finishes when the caller
needs the workflow result, and Immediately for
long‑running processes where the caller should not block. In
responseNode mode, always ensure the Respond to Webhook node is reached
for every request path to avoid silent 200 responses on error.
For a practical walkthrough, see
how trigger nodes initiate workflow execution.

How do you handle JSON, binary, raw body, and multipart form‑data payloads?

The Webhook node automatically parses incoming JSON
payloads and exposes them via {{ $json.body }} or
directly as {{ $json.fieldName }}. For
binary file uploads—PDFs, images, CSVs—n8n stores the
data in $input.item.binary under a configurable property
name (default: data). Use the Extract from File
node to read text‑based formats or the Convert to File
node to transform binary streams[reference:24].

Enable the Raw Body option to preserve the exact
byte‑for‑byte request body for cryptographic verification. When checked,
n8n stores the raw payload in a binary field alongside the standard
JSON output; downstream Code nodes decode it using
Buffer.from(binaryData).toString('utf8'). This is essential
for HMAC verification—hashing parsed JSON instead of the original bytes
produces a different signature and causes false rejections[reference:25].
For multipart/form‑data submissions containing both fields
and files, the Webhook node extracts form fields into
$json and converts each uploaded file into binary data
accessible under $input.item.binary. The Form Trigger node
is a specialised alternative that automatically manages multipart/form‑data
for user‑facing file uploads[reference:26]. For payloads exceeding 16 MB, self‑hosted
instances can raise the limit via N8N_PAYLOAD_SIZE_MAX; Cloud
instances are capped at 16 MB. For the complete CSV‑to‑JSON webhook pattern
supporting file upload, raw text in body, and pre‑structured JSON input
styles, see our
trigger nodes configuration guide.

How do you implement HMAC signature verification for production webhooks?

HMAC‑SHA256 verification is the gold standard for webhook security. It
requires the sender to sign the request body with a shared secret; n8n
recomputes the signature and compares it to the header value. The canonical
pattern chains six security layers: Webhook (Header Auth + Raw Body enabled),
Code node extracts the raw body as a UTF‑8 string, Code node computes
HMAC‑SHA256(timestamp.rawBody), Code node performs
timing‑safe comparison using
crypto.timingSafeEqual(), and payload validation rejects
unexpected fields before business logic runs[reference:27].

Invalid requests are returned with 403 Forbidden
(signature/timestamp failure) or 400 Bad Request (payload
validation failure), with no response body to avoid leaking internal
logic. For replay protection, include a timestamp and optional nonce in
the signed payload; the Code node rejects any request with a timestamp
older than a configurable window (default: 5 minutes). The community
Secure Webhook node bundles all six layers—plus IP allow/deny, per‑IP
rate limiting, Redis HA support, and mTLS header checks—into a single
hardened trigger that eliminates boilerplate Code nodes[reference:28].
For complete, importable HMAC verification templates targeting Stripe,
GitHub, and Seatable, see the
node security guide.

How does IP allowlisting work on the Webhook node, and what are its limits?

IP allowlisting on the Webhook node restricts access to specific IP ranges
configured as comma‑separated CIDR entries in the node’s Options
panel (e.g., 34.195.0.0/16, 54.208.0.0/15). Requests from IPs
outside the list are rejected before the workflow executes, adding a
network‑layer filter that complements application‑layer authentication for
defense‑in‑depth[reference:31].

A critical vulnerability: CVE‑2025‑68949 (CVSS 5.3 MEDIUM)
affected n8n versions 1.36.0 through 2.1.x, where the Webhook node’s IP
whitelist performed partial string matching instead of exact IP comparison.
An attacker whose IP shared a partial prefix with a trusted address could
bypass the allowlist—both IPv4 and IPv6 were impacted. The fix shipped in
version 2.2.0[reference:32][reference:33]. Always run n8n ≥ 2.2.0
if you rely on IP allowlisting, and never use IP allowlisting as the sole
security layer—combine it with HMAC or JWT authentication. For
self‑hosted deployments behind a reverse proxy, set
N8N_PROXY_HOPS so n8n correctly identifies the real client
IP rather than the proxy’s IP[reference:34]. For complete webhook
hardening combining IP filters with cryptographic verification, see
the node security guide.