Return Proper HTTP Status Codes with the Respond to Webhook Node

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.

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"
  }
}
```text
```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"
  }
}
```text
```json
// Branch 3: Synchronous lookup -- return 200
{
  "respondWith": "json",
  "responseCode": 200,
  "responseBody": "={{ { \"order\": $json.orderData } }}"
}
```text
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](../security-best-practices/01-set-a-unique-encryption-key-and-back-it-up.md) | [Use the HTTP Request Node as a Universal Connector](../integration-patterns/01-use-the-http-request-node-as-a-universal-connector.md)