Endpoint - Respond

Type identifier: endpoint:respond Category: Endpoint Operations

Description

Decides the HTTP response of an Endpoint (see Custom Endpoints) whose response source is Controlled by flow: the status, headers (including redirects and cookies), and a typed JSON body. The first response node a run reaches is the response; the node ends its path.

Input Handles

Handle	Data Type	Required	Description
`trigger`	`trigger`	Yes	Execution trigger input
`status`	`number`	No	The HTTP status, when the status is Dynamic
`header:{id}`	`string`	No	One per header row whose value is Dynamic, labelled with the header name
`body`	Varies	No	The response body. Not shown for a literal `204`, `205`, or `304`.

Input Handle Details

`body`

Type: Configurable via body.type; any schema type. When unconnected it defaults to any and adopts the type of whatever is connected, like Flow - Result.
Notes: Unconnected, the body is null. A connected value that doesn't match the declared type makes the response invalid (the endpoint responds 500).

Output Handles

This node has no output handles. It ends the path of the run.

Configuration Options

Property	Type	Required	Default	Description
`label`	`string`	Yes	`"Endpoint - Respond"`	Display label for the node
`status`	Number (literal or dynamic)	Yes	`{ type: "literal", value: 200 }`	The HTTP status, `200`–`599`
`headers`	Array of `{ id, key, value }`	No	`[]`	Response headers, sent in order
`body`	Schema type	Yes	`any` type	Declared type of the body input

Configuration Details

`status`

Validation: an integer from 200 to 599. A wired (dynamic) status outside that range makes the response invalid.
Notes: The editor suggests common statuses and accepts any other in range; select Dynamic? to wire the status from earlier nodes. For 204, 205, and 304 no body is sent, including when the status is wired.

`headers`

Validation: names must be valid HTTP header names and values must not contain line breaks or other control characters. Hop-by-hop headers, Content-Length, Content-Type, and platform-owned headers (compression, tracing, CORS, and security policy) are blocked; see How to Redirect and Set Cookies from an Endpoint — Limitations for the list. The editor flags a blocked name; at run time a blocked or invalid header makes the response invalid.
Notes: A name may repeat (for example, several Set-Cookie headers); each row has its own id, which names its input handle when the value is dynamic. For a 3xx status the editor offers to add a Location header. Cookies named ligantic.* (such as the App session cookie) are reserved: setting one makes the response invalid. On the App, a newly issued guest session cookie is sent alongside the Flow's cookies. The Studio preview doesn't send Set-Cookie.

Behaviour

Execution Flow

Resolves the status, the headers, and, unless the status is bodyless, the body.
Validates the response. If it's invalid, the reason is logged against the run and the endpoint responds 500.
Sets the endpoint's response to { status, headers, body }. It triggers no further nodes.

Which Response Is Sent

Only an endpoint whose response source is Controlled by flow uses response nodes. In Fixed response mode, response nodes are ignored.
The first response node the run reaches decides the response; later ones are ignored. Each branch of a Flow can end in its own response node.
If the run ends without reaching a response node, the endpoint's fixed status and body are the fallback. If the endpoint's timeout passes first, it responds 504; the run keeps going.
Response nodes inside a child Flow (started by Flow - Execute) don't affect the endpoint's response.

Examples

Branching Responses

[flow:trigger] → [control:if valid?]
                   ├─ true  → [object:create] → [endpoint:respond status 201, body ← Record]
                   └─ false → [endpoint:respond status 422, body ← errors]