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.

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.

A Webhook trigger acknowledges the request after queueing the run. Configure that trigger's response to customize the acknowledgement; a downstream Response block does not change it.

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.
ParallelWebhook