HTTP Response
Ends an ingress pipeline by answering the caller. The status code, headers and body all come from the message that reaches it.
Type: rest-response · Category: API · Ports: one input · no output
When to use it
- Every path through an ingress pipeline — success and failure alike
- Returning a created record, or an error the integrator can act on
Settings
None. The node answers the request that started the run, and everything about the answer is read from the message it receives — the payload first, then the message metadata:
| Field | Sets | When absent |
|---|---|---|
http_status | The status code | 200 — or 500 when error is set |
http_headers | Extra response headers, as an object of strings | — |
content_type | The Content-Type header | — |
error | Answer with {"error": "<text>"} instead of the payload | — |
Otherwise the payload is the response body: text is sent as it is, anything else as JSON. The
control fields are not removed from it, so a payload carrying http_status sends that field back
to the caller too.
Example — accepting or rejecting the order
A Python node in front of the response decides the outcome:
def transform(payload, message):
order = payload.get("body") or {}
if "orderId" not in order:
return {"http_status": 400, "error": "orderId is required"}
return {"http_status": 201, "accepted": order["orderId"]}
The caller gets 400 {"error": "orderId is required"}, or 201 with
{"http_status": 201, "accepted": "SO-4471"}.
Gotchas
- Every path needs one. A branch that ends without a response leaves the caller waiting for the
route's timeout, then a
504— which looks like a network fault from the other side and is far harder to diagnose than an error code. - It only answers a run a REST API ingress started. Anywhere else it fails with missing reply_to context in message. A Catch feeding it keeps that context, so an error handler can still answer the caller.