node cookbook
N8N Respond to Webhook Node Cookbook
Use Respond to Webhook when a Webhook-triggered workflow needs to control the HTTP response body, status code, headers, or response timing.
- Use when
- n8n workflows, webhooks, HTTP responses
- First check
- Confirm the workflow is active or published and the caller is using the production webhook URL.
- Time to check
- 5-10 minutes
- Next step
- Match the symptom, then run the verification checks.
Independent third-party notes. n8n is a trademark of its owner and is referenced only for compatibility and troubleshooting context.
Quick Answer
Use Respond to Webhook when a Webhook-triggered workflow needs to control the HTTP response body, status code, headers, or response timing.
Does this match your symptom?
Webhook is not reaching production
A test webhook works in the editor, but the production URL returns 404, uses the wrong method, or never creates an execution.
First check: Confirm the workflow is active or published and the caller is using the production webhook URL.
Version awareness
Last reviewed 2026-05-21
Key Facts
- Node role
- Send a response to an incoming Webhook request.
- Best fit
- Custom API endpoints, form callbacks, app webhooks, and synchronous response workflows.
- Common pairing
- Webhook node as the trigger.
- Common concern
- Caller timeouts can happen if the workflow waits too long before responding.
Recommended Steps
- Start the workflow with a Webhook node.
- Decide whether the caller needs an immediate response or a response after processing.
- Add Respond to Webhook where the response should be sent.
- Set status code, headers, and response body as needed.
- Test with curl or the external service and inspect the HTTP response.
Verification
- The caller receives the intended status code.
- The response body and headers match the integration requirement.
- The workflow execution still records the incoming payload and downstream result.
Warnings
- Long workflows can cause callers to time out before they receive the response.
- Do not return sensitive workflow data unless the endpoint is authenticated and intended to expose it.
Common Mistakes
- Expecting the Webhook node default response to satisfy a custom API contract.
- Returning too late after slow downstream processing.
- Forgetting content-type or status code requirements.
- Returning internal debug data to external callers.
Examples
Webhook receives request
Set builds response object
Respond to Webhook returns:
status: 200
body: { "ok": true, "received": true }Production Cookbook
Common production use cases
- Return provider acknowledgements.
- Send validation responses.
- Return a small JSON result to internal callers.
Required credentials/scopes
- No external credential, but response body must avoid secrets and private payloads.
Input fields that usually break
- Response code.
- Response body shape.
- Branch that never reaches the response node.
- Provider timeout window.
Common errors
- Webhook caller hangs.
- Wrong status code causes provider retries.
- Response includes internal debugging data.
{
"statusCode": 200,
"body": {
"ok": true,
"eventId": "evt_123"
}
}Small working pattern
Normalize event ID, perform the minimum required side effect, then return `{ ok: true, eventId }` quickly.
Related recipes using this node
When to use HTTP Request or Code instead: Use Code before this node only to build a safe response object; do not call external APIs inside response shaping when timeout is tight.
FAQ
Do I always need Respond to Webhook?
No. Use it when you need control over the response. The default Webhook behavior can be enough for simple triggers.
Why does the caller time out?
The workflow may be doing too much before responding. Respond earlier, then continue processing asynchronously where possible.