Return Proper HTTP Status Codes with the Respond to Webhook Node

By default the Webhook node returns 200 OK once the workflow finishes, which is wrong for many cases. Add a Respond to Webhook node on each branch to set the exact status code, headers, and body -- for example 400 for a validation failure, 202 for async processing, and 200 for a synchronous lookup -- so callers can use standard HTTP status handling.

Why set explicit HTTP status codes in n8n webhooks?

By default, the Webhook node returns 200 OK when the workflow finishes. This is wrong for many use cases. Use the Respond to Webhook node to control the exact status code, headers, and body returned to the caller. Proper status codes let calling systems distinguish between success, accepted-for-processing, and client errors.

Real-world example: A payment processor sends transaction notifications and expects 202 Accepted for async processing, 200 OK with a body for synchronous lookups, and 400 Bad Request when required fields are missing.

How do you return custom status codes with the Respond to Webhook node?

Configure the Webhook node with Response Mode set to Using 'Respond to Webhook' Node, then add Respond to Webhook nodes on each branch:

// Branch 1: Validation failed -- return 400
// Respond to Webhook node settings:
{
  "respondWith": "json",
  "responseCode": 400,
  "responseBody": "={{ { \"error\": \"missing_field\", \"message\": \"The field 'transaction_id' is required.\" } }}",
  "responseHeaders": {
    "Content-Type": "application/json"
  }
}

// Branch 2: Accepted for async processing -- return 202
{
  "respondWith": "json",
  "responseCode": 202,
  "responseBody": "={{ { \"status\": \"accepted\", \"tracking_id\": $json.trackingId } }}",
  "responseHeaders": {
    "Content-Type": "application/json"
  }
}

// Branch 3: Synchronous lookup -- return 200
{
  "respondWith": "json",
  "responseCode": 200,
  "responseBody": "={{ { \"order\": $json.orderData } }}"
}

What can callers do with proper status codes?

Callers can now use standard HTTP status handling. A 202 tells them not to wait for a result; a 400 tells them to fix their request before retrying.

Related: Set a Unique Encryption Key and Back It Up · Use the HTTP Request Node as a Universal Connector