Respond to Webhook node in n8n: take full control of your workflow HTTP responses

By default, an n8n Webhook node answers on its own: either immediately with a generic acknowledgment, or at the end of the workflow with the output of the last node. That is fine for receiving notifications, but as soon as the caller expects a real answer — structured JSON, a 400 status on invalid data, a redirect, a file — you need to take over. That is exactly what the Respond to Webhook node does: it decides what to send back, when to send it, with which HTTP status code and which headers. This guide covers its full configuration, the available response types, the patterns that get the most out of it (early response, 200/400 branching, mini REST API) and the traps to know about.

The Webhook node's three response modes

Everything starts with the Webhook node's Respond parameter, which offers three behaviors:

• Immediately: n8n replies as soon as the request arrives, with a standard confirmation message, then runs the workflow. The caller never learns whether processing succeeded.
• When Last Node Finishes: n8n waits for the workflow to finish and returns the data of the last executed node. Handy for simple cases, but you get no control over the status code, the exact shape of the response, or which branch answers.
• Using 'Respond to Webhook' Node: n8n keeps the HTTP connection open and only replies when a Respond to Webhook node is reached. This is the only mode that gives you full control.

That third setting is mandatory: without it, any Respond to Webhook node in the workflow is simply ignored. If the Webhook node basics (HTTP methods, test vs production URLs, authentication) are not in place yet, start with our complete n8n webhook guide.

Step-by-step setup

1. Add a Webhook node, pick the HTTP method (POST to receive data, GET for lookups) and set Respond to Using 'Respond to Webhook' Node.
2. Build your processing: validation, API calls, database queries, an AI agent.
3. Add a Respond to Webhook node wherever the response should leave — not necessarily at the end of the workflow, more on that below.
4. Pick the response type under Respond With, then adjust the status code and headers in the node options.
5. Test with the test URL, then activate the workflow to switch to the production URL. To test from an external service while your instance runs on your machine, see our article on testing n8n webhooks locally.

The available response types

The node's Respond With parameter determines what the caller receives:

• JSON: you write the response body yourself, with n8n expressions inside. The most common format for an API.
• First Incoming Item / All Incoming Items: returns the item(s) received by the node as-is, no reshaping — a quick way to expose a processing result directly.
• Text: a raw string, useful for integrations that expect a plain OK or minimal HTML.
• Binary: returns a file held in the item's binary data — a generated PDF, an image, a CSV export.
• Redirect: returns an HTTP redirect to a URL of your choice, for instance a thank-you page after a form submission.
• No Data: an empty body, when only the status code matters (a 204 after a deletion, a 202 for an accepted job).

Example JSON body for a validation endpoint:

{
  "status": "ok",
  "lead_id": "{{ $json.id }}",
  "score": {{ $json.score }},
  "message": "Request received, reply within 24h."
}

Custom HTTP status code and headers

In the node options, Response Code replaces the default 200 (201 for a creation, 400 for invalid input, 404 for a missing resource…), and Response Headers adds arbitrary headers: Content-Type for binary content, Cache-Control, or a custom header such as X-Request-Id to make client-side tracing easier. An explicit error code and body always beat a generic 200 that hides a failure.

Pattern 1: respond early, process afterwards

The Respond to Webhook node does not have to be the last one in the workflow. Placed right after reception and a quick validation, it acknowledges the request within a few hundred milliseconds, and then the workflow keeps running behind it: enrichment, an LLM call, database writes.

This is the essential pattern for services that enforce short response deadlines: Stripe marks a webhook as failed and retries it when the response is slow, and Slack expects an acknowledgment within 3 seconds for its interactions. As soon as an AI agent or a chain of API calls enters the processing, a synchronous reply becomes untenable — our article on webhook timeouts with an AI agent walks through that scenario. And since a provider that received no timely response often resends the same event, pair this pattern with an idempotency strategy to avoid duplicates.

The quick-acknowledgment reflex is not only about machines: a study by Fiona Fui-Hoon Nah published in 2004 in Behaviour & Information Technology, “A study on tolerable waiting time: how long are Web users willing to wait?”, puts a web user's tolerable waiting time for information retrieval at around 2 seconds, a threshold that feedback can extend. In other words, if your webhook backs a form or a widget, answering fast with a confirmation message and processing in the background is exactly what research on waiting perception recommends.

Pattern 2: multiple Respond to Webhook nodes behind an IF

A serious endpoint does not return 200 when the data is invalid. The typical structure of a form validation endpoint:

1. Webhook (POST, Respond set to "Using 'Respond to Webhook' Node").
2. IF: is the email present and well-formed? Are the required fields filled in?
3. False branch → Respond to Webhook with Response Code 400 and a JSON body { "error": "invalid_email" }.
4. True branch → processing (CRM, notification, scoring) → Respond to Webhook with a 200 and the result.

Each branch gets its own response node, with its own code and body. This pattern applies as-is when replacing a multi-step Form Trigger with a webhook, or to validate submissions from a custom form hosted on your site. Key point: every possible path must end in a Respond to Webhook node, otherwise the caller waits for nothing (see the traps below).

Pattern 3: a mini REST API with n8n

By combining several Webhook nodes (one per route and method) with structured responses, n8n becomes a lightweight API backend:

• GET /webhook/leads → database query → Respond to Webhook (JSON, 200);
• POST /webhook/leads → validation → insert → Respond to Webhook (201 with the created ID, or 400);
• POST /webhook/chat → LLM call with context → Respond to Webhook (JSON containing the model's answer).

That last case is exactly the architecture of an AI chat widget embedded in a website: the widget sends the question to the webhook, n8n queries the model (possibly with RAG), and the Respond to Webhook node returns the answer as JSON for the widget to display. The free RAG question-answering API workflow implements this pattern end to end, ready to import. Note the distinction with n8n's native REST API: that one drives n8n itself (workflows, executions, credentials), while your webhooks expose your own business endpoints.

A publicly exposed endpoint must be protected: header authentication, signature verification, IP filtering — the options are covered in our guide to securing an n8n webhook.

Traps and limitations to know

• Only one Respond to Webhook runs per execution. The first node reached sends the response and closes the HTTP connection; if the flow crosses a second one, there is no caller left to answer. Design your branches so an execution passes through exactly one response node.
• Timeout when no Respond node is reached. A branch that ends without a response node (an IF with an empty path, an error interrupting the flow before the reply) leaves the caller hanging until timeout. Check every path, error cases included.
• The Webhook node's mode wins. A Respond to Webhook node in a workflow whose Webhook is still set to "Immediately" or "When Last Node Finishes" is ignored — the first thing to check when "the node does nothing".
• No streaming. The node sends one complete response at once: you cannot stream an LLM's output token by token through it. For a chat, either accept the answer in a single block, or respond early and deliver the result through another channel.
• One response per request. You cannot "append" to a response already sent: to inform the caller about the outcome of asynchronous processing, plan a callback to a URL they provide, or a status-check endpoint.

Key takeaways

The Respond to Webhook node turns a passive n8n webhook into a real HTTP endpoint: it requires the Webhook node to be set to "Using 'Respond to Webhook' Node", offers six response types (JSON, incoming items, text, binary, redirect, empty body), and hands you control over the status code and headers. Three patterns to remember: respond early then keep processing to meet Stripe's or Slack's deadlines, branch several response nodes behind an IF for clean 200/400 handling, and assemble several webhooks into a mini REST API. The two golden rules: exactly one response node executed per run, and no workflow path that ends without a reply. To see the full API pattern in action, the free RAG question-answering API workflow is ready to import.