n8n Webhook Response Modes: On Received, Last Node, Respond

n8n webhook response mode controls when and how your workflow sends an HTTP response back to the caller. Immediately mode fires instantly with a generic message. Last Node waits for the entire workflow to finish. Respond to Webhook gives you full control over the response body, status code, and timing. Most n8n users pick the wrong one because no tutorial explains the trade-offs in plain terms.

The confusion is real. A 2019 community thread asked what response mode even means. A 2020 thread asked if customizing the On Received response was possible, and the n8n team said no. As of 2026, both answers are outdated. (The UI also relabeled "On Received" to "Immediately" along the way.) This guide corrects the record and gives you a clear framework for choosing the right mode.

What Is n8n Webhook Response Mode?

n8n webhook response mode is a setting on the Webhook node that determines when your workflow sends its HTTP response back to the calling service. The three options are On Received (immediately), When Last Node Finishes (after full execution), and Using Respond to Webhook Node (manual control).

Every n8n workflow that starts with a Webhook trigger must answer one question: does the caller need data back from the workflow, or is it just dropping off a payload?

If you're building a Zapier-style event trigger where a form submission fires off a chain of actions, you probably don't need a custom response. But if you're building a CRM integration where the calling service needs to confirm that a lead was created and get back a leadId, the response mode you pick changes everything.

I've built dozens of webhook-driven workflows for clients, and the response mode misconfiguration is the single most common reason their integrations break silently. The caller either times out waiting for a response that will never come, or gets back {"message": "Workflow got started."} instead of the data they need.

To put numbers on it: our production n8n instance at Rain Automation runs 51 workflows, many webhook-triggered. On our lead intake workflow alone (26 nodes, including CRM writes and conditional routing), the fast-path executions that return an immediate acknowledgment complete in 19-163ms (79ms average across 12 recent runs), while full-chain executions that wait for every node average 3,458ms. That gap is the difference between a caller getting a confirmation before they blink and a caller watching a spinner for 3.5 seconds.

Here's what each mode actually does, when to use it, and how to avoid the mistakes I see every week.

Step 1: Understand Immediately (On Received)

On Received tells n8n to send an HTTP 200 response the instant the webhook receives data, before any workflow nodes execute. The caller always gets back {"message": "Workflow got started."} regardless of what your workflow does afterward.

This is the default mode, and it's the right choice more often than people think.

When you set the Webhook node's Response Mode to "Immediately" (labeled onReceived in workflow JSON), here's what happens:

1. The calling service sends a POST (or GET) request to your webhook URL
2. n8n immediately returns HTTP 200 with {"message": "Workflow got started."}
3. The workflow begins executing in the background
4. The caller has already disconnected and moved on

You cannot customize the response body in this mode. That's by design. The n8n documentation is clear: Immediately mode is for async, fire-and-forget triggers.

Use Immediately when:

• A form submission triggers a background process (email sequence, Slack notification, database write)
• The calling service doesn't care about the workflow's output
• You need fast response times because the caller has a short timeout window
• You're processing jobs asynchronously and will notify the user separately (via email, SMS, or a status endpoint)

If you're setting up a Google Forms trigger workflow specifically, the n8n Google Forms trigger tutorial shows how to wire up the Sheets-based polling approach and which response mode fits each stage of that workflow.

One thing I always tell clients: if you're building a webhook lead capture workflow where a form just needs to know "yes, we got it," Immediately mode is perfect. No reason to make the form wait 3 seconds for your CRM API call to finish.

Step 2: Understand When Last Node Finishes

When Last Node Finishes tells n8n to hold the HTTP connection open until every node in the workflow completes execution, then return the output of the final node as the response body. The caller receives your actual workflow data instead of a generic message.

This mode turns your webhook into a synchronous API endpoint. The calling service sends a request, waits, and gets back real data.

Here's how it works:

1. The calling service sends a request to your webhook URL
2. n8n holds the connection open (no response yet)
3. The entire workflow executes, node by node
4. n8n returns the output of the last node in the chain as the HTTP response
5. HTTP status is always 200

This is where the responseData setting matters. When using Last Node Finishes, you choose between two options that change the shape of the JSON your caller receives.

responseData: All Incoming Items vs First Incoming Item (allEntries vs firstEntryJson)

Suppose your last node outputs two items. Here's what each setting returns:

allEntries returns an array of all output items:

[
  {
    "name": "Jane Doe",
    "email": "[email protected]",
    "leadId": "lead_001"
  },
  {
    "name": "John Smith",
    "email": "[email protected]",
    "leadId": "lead_002"
  }
]

firstEntryJson returns only the first item as a flat JSON object (no array wrapper):

{
  "name": "Jane Doe",
  "email": "[email protected]",
  "leadId": "lead_001"
}

If your caller expects a single object (which most API consumers do), use firstEntryJson. If you're returning a list of results, use allEntries.

The trade-off with Last Node Finishes is timeout risk. If your workflow takes a long time to run (maybe it calls three external APIs sequentially), the caller might time out before n8n sends the response. Timeout defaults vary widely by HTTP client: axios defaults to 0 (no timeout, waits forever), Python's requests library also has no default timeout, and cURL waits indefinitely unless you set --max-time. But many server frameworks and reverse proxies (nginx defaults to 60 seconds, for example) will cut the connection sooner. If your workflow takes more than 10-15 seconds, either optimize it or switch to Respond to Webhook so you can send an early acknowledgment.

For a deeper look at connecting CRM systems to n8n, the CRM integration tutorial covers the full setup.

Step 3: Understand the Respond to Webhook Node

The Respond to Webhook node gives you complete control over when the response fires, what HTTP status code to return, and what data to include in the body. It's the most flexible option and the correct choice for any workflow that needs conditional responses.

To use it:

1. Set the Webhook node's Response Mode to "Using Respond to Webhook Node"
2. Add a Respond to Webhook node anywhere in your workflow
3. Configure the status code (200, 201, 400, 500, etc.)
4. Set the response body (first item, all items, or custom JSON)

This mode solves the problem that frustrated users back in 2020. The original question was: "Is it possible to customize the webhook's response when using On Received mode?" The n8n team answered "No, sorry" at the time. That answer was correct then, but the Respond to Webhook node was added to n8n specifically to address this gap. If you found that old thread and thought custom responses were impossible, they're not. The Respond to Webhook node is the solution.

Here's what makes this mode powerful:

• Custom HTTP status codes. Return 201 for created resources, 400 for validation errors, 500 for server failures. Last Node and On Received always return 200.
• Conditional responses. Use an IF node to route to different Respond to Webhook nodes. Valid data gets a 201 success response. Invalid data gets a 400 error response with details.
• Custom JSON body. You can use expressions to build exactly the response structure your caller expects.
• Timing control. Place the Respond to Webhook node early in the workflow to send a quick response, then continue processing. The caller gets a fast reply while background work finishes.

So you can build a workflow that validates the incoming data, sends a 400 if something is missing, or sends a 201 with a confirmation object if everything checks out. Then continues processing downstream (sending emails, updating a CRM) after the response is already sent. If you need help setting up that downstream email step, the full breakdown of every Send Email node field covers SMTP credentials, sender name, attachments, and HTML vs plain-text options.

This pairs well with n8n lead capture templates that need confirmation responses.

The Three Response Modes at a Glance

This comparison table is the quickest way to pick the right n8n webhook response mode for your use case. Each column covers the dimension that matters most when the choice goes wrong: what the caller actually receives.

Dimension	Immediately	Last Node Finishes	Respond to Webhook Node
When n8n responds	Immediately, before workflow runs	After all nodes finish	When the Respond to Webhook node executes
Default response body	{"message": "Workflow got started."}	Output of last node (JSON)	You define it (custom JSON, items, or expression)
HTTP status code	Always 200	Always 200	You choose (200, 201, 400, 500, etc.)
Customizable body	No	Partial (whatever the last node outputs)	Full control
Timeout risk	None (instant response)	High for long workflows (proxy/server timeouts)	Low (you control when it fires)
Best for	Fire-and-forget triggers, async jobs	Simple request-response APIs	CRM confirmations, conditional error handling, partial async
responseData options	Not applicable	allEntries or firstEntryJson	All Incoming Items, First Incoming Item, or custom JSON
Conditional responses	Not possible	Not possible	Yes, via IF node routing to multiple Respond nodes

Compared to On Received, Last Node gives you data back but no status code control. Compared to Last Node, Respond to Webhook adds custom status codes and conditional branching. The trade-off is complexity: On Received requires zero configuration, while Respond to Webhook requires placing and configuring an extra node.

Step 4: Build a CRM Lead Capture Workflow (Practical Example)

This CRM lead capture example demonstrates the Respond to Webhook node in a real business workflow: an external form POSTs lead data, n8n creates the lead in your CRM, and the webhook responds with a custom 201 confirmation including the new lead ID.

Here's the complete workflow, step by step.

Webhook Node Configuration

Set up the trigger:

• HTTP Method: POST
• Path: /lead-capture
• Authentication: Header Auth (use an API key so only your form can trigger it)
• Response Mode: Using Respond to Webhook Node

Validation with IF Node

After the Webhook node, add an IF node to check that required fields exist:

• Condition: {{ $json.email }} is not empty AND {{ $json.name }} is not empty
• True branch: proceed to CRM creation
• False branch: route to an error Respond to Webhook node

Error Response (Respond to Webhook Node)

On the false branch, add a Respond to Webhook node:

• Response Code: 400
• Response Body (JSON):

{
  "success": false,
  "error": "Missing required fields: name and email are required"
}

CRM Lead Creation (HTTP Request Node)

On the true branch, use an HTTP Request node to create the lead in your CRM:

• Method: POST
• URL: https://api.yourcrm.com/v1/contacts
• Body: Map name, email, phone, and source from the webhook payload

The CRM API returns the new record with a leadId field.

Success Response (Respond to Webhook Node)

After the HTTP Request, add another Respond to Webhook node:

• Response Code: 201
• Response Body (JSON):

{
  "success": true,
  "leadId": "{{ $json.id }}",
  "message": "Lead created successfully"
}

The calling form receives a 201 with the lead ID, confirming the record was created. If you're building this kind of integration, the complete CRM integration guide walks through the CRM-side configuration.

This pattern works with HubSpot, Salesforce, Pipedrive, or any CRM with a REST API. For HubSpot specifically, the n8n HubSpot integration tutorial has the exact node settings.

Which n8n Webhook Response Mode Should You Use? (The ACR Framework)

Pick On Received for speed, Last Node for simplicity, and Respond to Webhook for control. The decision comes down to one question: does the caller need data back from your workflow?

I call this the ACR framework: Async, Complete, Respond. Each letter maps to one mode. Async (On Received) fires and forgets. Complete (Last Node) waits for the full result. Respond (Respond to Webhook) gives you manual control. When a client asks me which mode to use, I walk them through ACR in under two minutes.

Use On Received if:

• The caller only needs acknowledgment that the data arrived
• Your workflow runs background tasks (notifications, database writes, email sequences)
• Speed matters and you can't risk timeouts
• You're building an automated lead capture where the form just needs a 200 OK

Use Last Node if:

• The caller needs the workflow's output data
• Your workflow completes in under 10 seconds
• You don't need custom HTTP status codes (200 is fine for all cases)
• You're building a simple data transformation API (receive data, process, return result)

Use Respond to Webhook if:

• You need custom HTTP status codes (201 for created, 400 for bad request)
• Different inputs should produce different responses (conditional branching)
• You want to respond quickly but continue processing in the background
• You're building a production API that external services depend on
• You need error handling with descriptive error responses

Here's the thing: when in doubt, use Respond to Webhook. It's more configuration upfront, but it gives you flexibility you'll need later. A SaaS client (Marcus at a B2B onboarding platform) hit this wall in Q3 2025. He started with Last Node for a lead capture workflow. Three months in, his team needed to return different responses for duplicate leads vs new leads, and Last Node couldn't branch. Switching to Respond to Webhook with an IF node took about 15 minutes and eliminated the duplicate-lead confusion his sales team had been complaining about for weeks. If he'd started with Respond to Webhook, it would have been a 5-minute change.

Common Mistakes and How to Fix Them

The most common n8n webhook response mode mistake is setting On Received but expecting custom data in the response. As this February 2026 community thread shows, developers regularly hit this exact pattern and get confused when the response ignores their Respond to Webhook node.

Here are the mistakes I see most often, and the fix for each.

Mistake 1: Using On Received with a Respond to Webhook Node

If you set the Webhook's Response Mode to On Received but also add a Respond to Webhook node in your workflow, the Respond node does nothing. n8n already sent the response before your workflow started. The fix: change the Webhook's Response Mode to "Using Respond to Webhook Node."

Mistake 2: Caller Timing Out on Last Node

If your workflow takes 45 seconds (multiple API calls, file processing, etc.) and the caller's server or reverse proxy enforces a timeout (nginx defaults to 60s, many cloud platforms use 30s), the caller disconnects before getting a response. n8n still runs the workflow, but the response is lost.

Fix: Switch to Respond to Webhook and place the response node early in the workflow. Return an acknowledgment with a tracking ID, then continue processing. Or optimize your workflow to run under 15 seconds. For lead routing workflows, keep the webhook response lightweight and do heavy processing after the response.

Mistake 3: Returning an Array When the Caller Expects an Object

With Last Node Finishes, the default responseData is allEntries, which wraps the output in an array. If the caller expects a flat JSON object, they'll get parsing errors. Fix: set responseData to firstEntryJson, or switch to Respond to Webhook for explicit body control.

Mistake 4: Forgetting Authentication on Production Webhooks

This isn't about response modes, but it comes up in every webhook debugging session. An unauthenticated production webhook means anyone who finds the URL can trigger your workflow. Use Header Auth or Basic Auth on the Webhook node for any production deployment. The webhook lead capture setup guide covers auth configuration.

Mistake 5: Not Testing with Postman or cURL

n8n's built-in test webhook is helpful, but it doesn't show you exactly what the caller receives. Always test your production webhook with cURL or Postman to see the actual HTTP status code, response headers, and body.

Here's a quick cURL test:

curl -X POST https://your-n8n-instance.com/webhook/lead-capture \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"name": "Test Lead", "email": "[email protected]"}' \
  -v

The -v flag shows the full response including status code and headers.

Advanced Pattern: Dual-Response Async Workflows

For workflows that need both an immediate acknowledgment and a later callback, you can combine the Respond to Webhook node with a second HTTP Request node that sends results back to the caller's callback URL.

Picture this: you've built a workflow that processes uploaded images (resizing, watermarking, uploading to cloud storage). The processing takes 60 seconds. The caller can't wait that long.

The pattern:

1. Webhook receives the request with a callbackUrl field in the payload
2. Respond to Webhook fires immediately with {"status": "processing", "jobId": "abc123"}
3. The workflow processes the image (resize, watermark, upload)
4. An HTTP Request node POSTs the result to the caller's callbackUrl

This is the same pattern used by transcription APIs and many async processing services. Deepgram and AssemblyAI both accept a callback_url parameter and POST results asynchronously after processing completes. It works well for any n8n workflow where processing time exceeds 10 seconds. The n8n vs Zapier comparison covers why this kind of flexibility is a key advantage of self-hosted automation.

Frequently Asked Questions

What is the difference between On Received and Last Node response modes in n8n?

On Received sends an instant HTTP 200 with a fixed message before the workflow runs. Last Node holds the connection open, executes the entire workflow, and returns the final node's output as the response. On Received is for fire-and-forget; Last Node is for request-response patterns where the caller needs data.

How do I send a custom JSON response from an n8n webhook?

Set the Webhook node's Response Mode to "Using Respond to Webhook Node." Then add a Respond to Webhook node in your workflow and configure the response body as custom JSON. You can use n8n expressions to include dynamic data like record IDs or validation messages.

Why does my n8n webhook return "Workflow got started" instead of my data?

Your Webhook node's Response Mode is set to "On Received," which always returns that fixed message. Switch it to "When Last Node Finishes" to return your workflow's output, or to "Using Respond to Webhook Node" for full control over the response.

How do I return a custom HTTP status code from an n8n webhook?

Only the Respond to Webhook node supports custom status codes. Set the Webhook's Response Mode to "Using Respond to Webhook Node," add the Respond node, and set the Response Code field to 201, 400, 500, or any valid HTTP status. The On Received and Last Node modes always return 200.

Can n8n webhook respond with data from a CRM after creating a record?

Yes. Set the response mode to Respond to Webhook, create the CRM record with an HTTP Request node, then use a Respond to Webhook node after the creation step. Map the CRM's response (including the new record ID) into your webhook response body.

What is responseData All Incoming Items vs First Incoming Item (allEntries vs firstEntryJson) in n8n?

These settings control the shape of the JSON response when using Last Node Finishes mode. allEntries wraps all output items in an array. firstEntryJson returns only the first item as a flat object without the array wrapper. Most API callers expect a flat object, so firstEntryJson is usually the right choice for single-record responses.

Next Steps

Now that you know which n8n webhook response mode to use, you can build production-ready webhook workflows without the guesswork.

If you're setting up a CRM integration, start with the n8n CRM integration tutorial for the full walkthrough. For lead capture specifically, the step-by-step guide covers webhook configuration, authentication, and CRM mapping. If your webhook-triggered workflow sends email downstream and that step stops working, the five most common Send Email node failures in n8n and how to fix them is the right next stop.

Building something more complex? The guide to building custom AI agents with n8n shows how webhooks connect to AI-powered workflows. And if you're comparing n8n to other platforms, the n8n vs Make comparison breaks down where each tool fits.

Need help designing a webhook workflow for your business? Schedule a call and we'll map out the right architecture for your use case.

This post contains affiliate links. If you sign up for n8n through our link, we may earn a commission at no extra cost to you. We only recommend tools we use ourselves.