Variables and Response Capture in Workflow Chain Engine
{name} placeholders, HTTP nodes capture response values back into them, and the run history shows their final values when the flow ends. This guide covers the whole life cycle, and the capture syntax that turns any API response into data your next node can use.
Declaring Variables
Each workflow declares its variables by name on its settings page, customer, email, total, whatever the flow works with. Declaring them does two practical things: the Run Now button grows an input box per variable, so testing is typing values into a form, and the workflows API reports them, so outside systems know what the flow expects. Variables start each run as empty text, ready to be filled.
Filling Them: The Trigger
Whatever the trigger sends becomes variable values at the start of the run. A webhook's body fields and query string fields map by name, the run API's extra body fields do the same, Run Now takes its input boxes, and scheduled runs start with empty variables and fill them through the flow's own first nodes. One rule, every trigger: fields in, variables filled. The triggers guide has each request shape.
Using Them: Placeholders in Any Field
Any node field can include {name} placeholders, and resolution replaces every occurrence inside the string, so placeholders compose naturally into larger text:
URL: https://api.example.com/orders/{orderID}
Fields: customer={customer}&flag=review
Headers: Authorization=Bearer {token}
Message: Processed {customer}, total {total}.That composability is the quiet superpower: request bodies, URLs, headers, condition values, and end messages are all just strings with holes in them, and the same {name} syntax fills every hole. A Set Variable node uses the same resolution in its value, which makes it the string builder, Order {orderID} for {customer} assembles a message any later node can send or return.
Capturing: Getting Data Back Out of APIs
The HTTP Request node's Capture Response Fields turns responses into variables, with three forms:
| Capture | What it does |
|---|---|
myVar={status} | Finds the first status key anywhere in the JSON response, at any depth. The right tool when you know the field name and the API's nesting is not worth memorizing. |
total={data.total} | Walks that exact path through the response. The right tool when the response has the same field name in several places. |
items={data.items} | Captures an array, stored ready for a For Each loop. |
When the response is not JSON, the first capture receives the whole response text, so plain text endpoints feed variables too. And since HTTP error statuses keep the run going, capturing {status} and branching on it with an If node is the standard pattern for handling an API's application-level answers.
Loops: loopItem and loopIndex
Inside a For Each loop, two extra variables appear: {loopItem} is the current element and {loopIndex} is its position. A captured JSON array, or comma or newline separated text, walks item by item, and each pass through the loop body can call APIs, branch, and build strings with the current item in hand. The classic combination is capture an array, loop it, and post each item somewhere, three nodes for a batch job.
Reading Them: The End of the Run
When a flow ends, the Success or Fail message resolves its placeholders and becomes the response the trigger sees, and the run history stores every variable's final value alongside the step log. That last part turns the variable pool into a debugging instrument: whatever state the flow reached, the history shows it, covered in depth in run history and debugging.
Patterns Worth Stealing
- Defaults first. A Set Variable right after Start gives a variable its fallback, and trigger-supplied values simply arrive already filled, so the flow works with or without the optional field.
- Normalize early. Capture an API's field into the same variable name every flow uses, and downstream nodes stay identical across data sources.
- Compose messages as you go. Build a running summary in a variable inside a loop, then return it in the Success message, the caller gets the whole story in one line.
- Branch on emptiness. A length check on a captured variable is the universal "did we get anything" test after an HTTP node.
One flat pool of named values powers everything: triggers fill it, {name} placeholders read it from any field with every occurrence resolved, captures write API responses back into it by first-match, exact path, or array, and the run history shows its final state. Master the pool and every flow becomes easy to reason about.