---
title: Response
description: The Response block ends an API-triggered workflow and returns a structured HTTP response.
pageType: reference
---

import { Callout } from 'fumadocs-ui/components/callout'
import {
  BlockPreview,
  WorkflowPreview,
  RESPONSE_API_WORKFLOW,
  RESPONSE_ERROR_WORKFLOW,
  RESPONSE_WEBHOOK_WORKFLOW,
} from '@/components/workflow-preview'
import { FAQ } from '@/components/ui/faq'

The **Response block** ends a workflow and returns a structured HTTP response to the caller. Use it with an [API deployment](/workflows/deployment/api) to control the exact body, status code, and headers that come back.

<BlockPreview type="response" />

<Callout type="info">
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](/workflows/blocks/router) or [Condition](/workflows/blocks/condition)); the first to run determines the response.
</Callout>

## 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](/workflows/connections), or a [workflow variable](/workflows/variables) like `<variable.userId>`. Nest objects and arrays freely.

```json
{
  "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:

| Key | Value |
| --- | --- |
| Content-Type | application/json |
| Cache-Control | no-cache |
| X-API-Version | 1.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.

<Callout type="warn">
Don't place a Response block in [parallel](/workflows/blocks/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.
</Callout>

## Examples

### Return data from an API endpoint

<WorkflowPreview workflow={RESPONSE_API_WORKFLOW} />

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

### Acknowledge a webhook

<WorkflowPreview workflow={RESPONSE_WEBHOOK_WORKFLOW} />

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

<WorkflowPreview workflow={RESPONSE_ERROR_WORKFLOW} />

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.

<FAQ items={[
  { question: "Can I have multiple Response blocks in a workflow?", answer: "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." },
  { question: "What triggers require a Response block?", answer: "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." },
  { question: "What is the difference between Builder and Editor mode?", answer: "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." },
  { question: "What is the default status code?", answer: "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." },
  { question: "Can the Response block connect to downstream blocks?", answer: "No. Response blocks are exit points — they end execution and send the HTTP response, so no block runs after one." },
]} />
