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.