Reference

Response

The Response block ends a workflow and returns a structured HTTP response to the caller. Use it with an API deployment to control the exact body, status code, and headers that come back.

Response
Response Data ModeBuilder
Response Structure-
Status Code-
Response Headers-
error

A Response block is an exit point. When one runs, the workflow ends and the HTTP response is sent immediately. You can place several on different branches (after a Router or Condition); the first to run determines the response.

Configuration

Response Data Mode

Builder lays out the response body field by field with types; Editor is a raw JSON code editor. Builder fits most cases.

Response Data

The body sent back, as JSON. Reference any earlier value: a block output like <agent.content> with a connection tag, or a workflow variable like <variable.userId>. Nest objects and arrays freely.

{
  "query": "<start.input>",
  "answer": "<agent.content>",
  "model": "<agent.model>"
}

Status Code

Any valid HTTP status code; defaults to 200. Set 4xx or 5xx on error branches (201 created, 400 bad request, 404 not found, 500 server error).

Response Headers

Extra response headers, as key-value pairs:

KeyValue
Content-Typeapplication/json
Cache-Controlno-cache
X-API-Version1.0

Outputs

A Response block is a terminal block, so nothing reads from it. Its data, status, and headers become the HTTP response itself. A workflow with no Response block returns its last block's output by default; add a Response block when you need exact HTTP control.

Don't place a Response block in parallel with blocks that have important side effects. Order across parallel branches is non-deterministic, so the Response may fire before or after them on any given run.

Examples

Return data from an API endpoint

The Response block reads <agent.content> into its body and returns 200 to the API caller.

Acknowledge a webhook

After processing the payload, the Response block returns a small confirmation so the sender knows the event was received.

Return a different status per branch

A Condition routes valid requests to a 200 Response and invalid ones to a 400. The first Response to run determines what the caller gets.

Best Practices

  • Use accurate status codes. 2xx for success, 4xx/5xx for errors, set per branch.
  • Keep a consistent response shape across your endpoints so callers can rely on it.
  • Return a different response per outcome. Put a Response on each branch after a Condition or Router.
  • Check your references resolve. A connection tag pointing at a block that did not run comes back empty, so set fields on the branch that produces them.

Common Questions

Yes. Place them on different branches (after a Router or Condition). The first Response block to run determines the API response and ends the workflow — for example a 200 on the success branch and a 500 on the error branch.
It is designed for the API trigger. When the workflow is invoked over the API, the Response block sends the structured HTTP response back to the caller. Other triggers like webhooks or schedules don't require one.
Builder mode is a visual interface for constructing the response structure with fields and types. Editor mode is a raw JSON editor where you write the response body directly. Builder mode suits most cases.
If you don't set one, the Response block returns 200 (OK). You can set any valid HTTP status code, including error codes like 400, 404, or 500.
No. Response blocks are exit points — they end execution and send the HTTP response, so no block runs after one.

On this page