How to Redirect and Set Cookies from an Endpoint

This guide shows you how to let a Flow decide an Endpoint's response (see Custom Endpoints): redirect the caller, set cookies, or return a status other than the Endpoint's fixed one.

Prerequisites

• An Endpoint whose handler Flow you can edit (see How to Create an Endpoint).
• Admin access to the Space.

Steps

1. Open the Endpoint's handler Flow and add an Endpoint - Respond node (endpoint:respond) at the end of each path that should respond. Connect a trigger node to it.
2. Set the node's Status, for example 302 for a redirect.

3. Under Headers, click + for each header to send:

   • Location — where to redirect. For a 3xx status the node offers Add Location if it's missing. Select Dynamic? to wire the URL from earlier nodes, for example a payment session URL from an Integration - HTTP (integration:http) node.
   • Set-Cookie — one row per cookie, for example cart=abc123; Path=/; HttpOnly; Secure; SameSite=Lax.
   • Others as needed, for example Cache-Control: no-store.
4. Optionally connect a Body. Statuses 204, 205, and 304 never send a body.
5. Publish the Flow.
6. In Space Settings → Endpoints, open the Endpoint and set Response → Source to Controlled by flow. The fixed status and body become the fallback, used when a run ends without reaching an Endpoint - Respond node.
7. Publish the Endpoint.

Result: Callers receive the status, headers, and body set by the first Endpoint - Respond node the run reaches. A run that ends without reaching one returns the Endpoint's fixed status and body.

Warning: Validate redirect targets. Don't wire request input straight into Location; check it against the destinations you expect, or a caller can turn the Endpoint into an open redirect.

Example: Redirect to Checkout

[flow:trigger] → [integration:http create checkout session]
                   → [endpoint:respond
                        Status 303
                        Location   ← http result.url (dynamic)
                        Set-Cookie   cart={id}; Path=/; HttpOnly
                        Cache-Control no-store]

Limitations

• Blocked headers. A Flow can't set hop-by-hop headers (Connection, Transfer-Encoding, ...), Content-Length, Content-Type (responses are JSON), or headers Ligantic owns: Content-Encoding, Server-Timing, X-Powered-By, CORS (Access-Control-*, Cross-Origin-*), and security policy headers (Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Permissions-Policy, Referrer-Policy). Header names and values with invalid characters, such as line breaks, are rejected. A response with a blocked or invalid header fails with 500.
• Reserved cookies. Cookies named ligantic.*, such as the App session cookie ligantic.identity.app.session, are reserved: a Flow can't set, overwrite, or clear them. The Flow editor flags a literal one, and a response that sets one fails with 500. When the App issues a guest session for the request, its session cookie is sent alongside the Flow's cookies.
• Preview. The Studio preview front door doesn't send Set-Cookie headers, so Flow cookies never land on the Studio domain. Test cookies on the published App URL.