younifyd
Menu

HTTP Response Connector

End a workflow route by sending a custom HTTP response — built directly (status, headers, body) or forwarded from a previous step's own response.

Browse 2 HTTP Response actions http
On this page

What this connector is for

Ends a workflow route by sending a specific HTTP response back to whatever called it — either one you construct yourself (Send Raw Response) or one that reuses a previous step's own output (Send Response From Step). Whichever action runs, the route stops there: no step configured after it will execute, so referencing this step's own output from a later step isn't meaningful.

All fields are listed in the action reference.

Send Raw Response

Builds the response from a status code, headers and body.

  • Status defaults to 200 and must be 100 to 599.
  • If a Content-Type of application/json is in effect (explicit or the default) and the body parses as valid JSON, it is sent as parsed JSON; otherwise the body is sent exactly as typed, even if it looks like invalid JSON.
  • Content-Type defaults to application/json, applied only if neither Response Headers nor the body handling already set a Content-Type/content-type header.

Example

text
HTTP Status Code: 404
Response Headers: Content-Type: application/json
Response Body: {"error": "Order not found"}

Send Response From Step

Forwards a previous step's response to the caller. Select Step takes the whole response envelope ({{<stepReference>.response}}, shaped { status, headers, data }), not just .data.

  • Its status becomes this response's status only if it is a number between 100 and 599; otherwise 200.
  • Its headers are copied across minus hop-by-hop/transport headers that would be wrong to re-serve: content-encoding, transfer-encoding, connection, keep-alive, upgrade, proxy-authenticate, proxy-authorization, te, trailer, cf-ray, cf-cache-status, cf-request-id, x-envoy-upstream-service-time, server, date, etag, vary.
  • Its data becomes the body, forwarded as-is.
  • Additional Response Headers are merged on top and override same-named headers. If no Content-Type ends up set, it defaults to application/json.

Example

Forward a previous "Get Order" step (reference getOrder) to the caller, adding a header:

text
Select Step: {{getOrder.response}}
Additional Response Headers: Cache-Control: no-store

The caller receives getOrder's own status, headers and body, plus Cache-Control.

Also applies here

Step Name

What it's for

Every step in a workflow gets a name — either one you set or a default based on the connector and action (e.g. "Get Order Details", "Send Welcome Email"). It's shown throughout the UI and in your execution history, and it's also the source for the step's Reference — a camelCase identifier auto-generated from the name (e.g. "Get Order Details" → getOrderDetails) — which is what you actually use in {{...}} expressions to read this step's output from later steps. See Step Reference.

Rules

  • Must be at least 2 characters, and 50 characters or fewer.
  • Must be unique within the workflow — reusing a name that's already taken will be rejected, with a suggested alternative (e.g. "Get Order Details 2").
  • Can't be empty.

Tips

  • Prefer a descriptive, human-readable name over a generic one — "Get Order Details" is easier to work with later than "HTTP Request 2", especially once a workflow has a dozen steps.
  • Renaming a step updates every reference to it elsewhere in the workflow automatically.
Was this page helpful?

Last updated 9 October 2026