Respond Node

The Respond node is the final destination for synchronous workflows, enabling you to construct and send HTTP responses back to the client. Whether you're building a REST API, a webhook handler, or a real-time streaming application, this node gives you granular control over the response body, headers, status codes, and Server-Sent Events (SSE).

Overview

The Respond node serves as the exit point for data in synchronous workflows. Unlike asynchronous workflows that simply finish execution, synchronous workflows (triggered by HTTP Listeners or Webhooks) need to return data to the caller. The Respond node allows you to format this data, set the appropriate HTTP status code, and manage headers.

Key Capabilities

Use Cases

• API Endpoint Construction: Return processed data to a frontend application or third-party service.
• Webhook Acknowledgement: Send a specific status code (e.g., 202 Accepted) to acknowledge receipt of a webhook.
• Real-time Progress Updates: Stream step-by-step progress of a long-running AI task to a user interface.
• Conditional Responses: Return different status codes and messages based on workflow logic (e.g., 404 if data not found).

Integration with Webhook Trigger Modes

The behavior of the Respond node is fundamentally determined by the Response Mode selected in your Webhook Trigger or HTTP Listener.

1. Synchronous Modes

Wait (Standard)

• Behavior: The client request hangs until the workflow reaches a Respond node.
• Respond Node Role: Constructs the final HTTP response.
• Workflow: Request → Workflow Execution → Respond Node → Response Sent → End.

Node (Early Response)

• Behavior: The client waits for a response, but the workflow continues running after the response is sent.
• Respond Node Role: Sends the response to unblock the client.
• Workflow: Request → Workflow Execution → Respond Node (Response Sent) → Continued Execution → End.
• Use Case: Long-running background tasks where you need to return a specific ID or status to the client before finishing.

2. Streaming Modes

SSE (Server-Sent Events)

• Behavior: The connection remains open, and data is streamed to the client.
• Respond Node Role: Acts as an event emitter. Each Respond node sends a single event to the stream.
• Workflow: Request → Respond Node 1 (Event A) → Respond Node 2 (Event B) → ... → End (Stream Closed).

3. Asynchronous (Partial) Modes

In these modes, the Webhook Trigger immediately returns a 202 Accepted response to the client before the workflow starts.

Immediate / Async Callback / Polling

• Behavior: The initial HTTP response is handled entirely by the Trigger.
• Respond Node Role:
  • Immediate: The Respond node is generally not used for the HTTP response, as the client has already disconnected.
  • Async Polling: The Respond node defines the final payload that the client receives when they poll the completion endpoint.
  • Async Callback: The Respond node defines the payload sent to the configured callback URL.

Configuration Guide

The Respond node adapts its interface based on the Response Mode configured in your workflow's trigger (HTTP Listener or Webhook).

1. Response Body Configuration

You can define the body of your HTTP response using either a static value or dynamic mapping.

Static Response

Use this for fixed messages or simple acknowledgements.

• Enable: Toggle "Static Response" on.
• Content: Enter raw text or JSON.
• Example: {"status": "received", "message": "Processing started"}

Dynamic Response

Use this to return data generated during the workflow execution.

• Field Mapping: Map fields from previous nodes to the response JSON structure.
• Source: Select the node and field you want to include.
• Target: Define the key name in the response JSON.

Example Mapping:

Resulting JSON:

{
  "answer": "The capital of France is Paris.",
  "user_id": "12345",
  "processed_at": "2023-10-27T10:00:00Z"
}

2. SSE Event Configuration (Streaming Mode)

When your workflow trigger is set to SSE (Server-Sent Events) mode, the Respond node transforms into an event emitter. You can place multiple Respond nodes in your workflow to stream updates at different stages.

Configuration Options:

• Event Name: The name of the event that clients will listen for (e.g., progress, result, error).
• Include Node Metadata: Automatically adds node_id and timestamp to the event payload.
• Mark as Final Event: If enabled, the SSE connection will be closed after this event is sent.

Example SSE Output:

event: progress
data: {
  "node_id": "respond_node_1",
  "timestamp": "2023-10-27T10:00:01Z",
  "payload": {
    "step": "analyzing_document",
    "percentage": 50
  }
}

3. Response Override (Node Mode)

When the trigger is set to Node mode, the workflow continues executing even after a response is sent. The Respond node allows you to override the default response behavior at specific points.

• Override Status Code: Change the HTTP status code (e.g., force a 400 Bad Request if validation fails).
• Add Response Headers: Inject specific headers for this response, which are merged with the trigger's default headers.

4. Custom Headers

You can add custom HTTP headers to any response, regardless of the mode.

• Key: The header name (e.g., X-Custom-Header, Cache-Control).
• Value: The header value (e.g., value-123, no-cache).

Common Use Cases:

• Cache-Control: max-age=3600 (Caching policies)
• Content-Type: application/xml (Overriding content type)
• X-Rate-Limit: 100 (Custom API metadata)

Best Practices

Structured Error Handling

Use the Respond node in combination with Router nodes to handle errors gracefully.

1. Use a Router Node to check for error conditions (e.g., data == null).
2. Route the error path to a Respond Node configured with:
   • Status Code: 400 or 404 or 500.
   • Body: {"error": "Resource not found", "code": "NOT_FOUND"}.

Progressive Streaming

For long-running AI workflows, use multiple Respond nodes to keep the user engaged.

1. Start: Send an "acknowledged" event immediately.
2. Progress: Send "progress" events after each major step (e.g., "Searching knowledge base...", "Generating answer...").
3. Final: Send the final "result" event and mark it as the Final Event to close the stream.

Security Headers

Always consider adding security headers if your API is public facing.

• Strict-Transport-Security
• X-Content-Type-Options: nosniff

Troubleshooting