Node Types
Every flow is assembled from seven kinds of node. This page covers what each does and its ports at a glance; Loop, Sub-flow, and Script get their own deep-dive pages linked below since they have the most moving parts.
The entry point of a flow. Every new flow gets one automatically — you can't add or delete it. It has a single out-port and no settings; connect it to whatever should run first.
Request
Section titled “Request”Runs one HTTP request from a Composer collection. This is the node you'll use most.
- Ports: one in-port, one out-port.
- Settings:
- Which saved request it references (set by dragging a request from the sidebar onto the canvas).
- Extractions — named values pulled out of the response (body path, header, or status) that downstream nodes can reference as
{{thisNode.outputs.name}}. See Variables & Extractions. - Assertions — checks against the response. Either declarative (pick a source, an operator —
equals,notEquals,contains,lessThan,greaterThan,exists,matches— and an expected value) or a script assertion usingpro.test/pro.expect. See Scripting in Flows.
A request node fails if the request errors (network failure, timeout) or any of its assertions fail. A failed node publishes no outputs — anything downstream that references {{thisNode.outputs.x}} sees an unresolved reference and fails in turn.
Condition
Section titled “Condition”Branches the flow based on a value.
- Ports: one in-port, two out-ports labeled true and false. Each out-port can hold at most one edge (no fan-out on a single branch — wire multiple nodes off the branch's single edge if you need to run several things).
- Settings: a left value (typically a
{{...}}reference), an operator, and a right value/expected value — the same operator set as assertions.
Whichever branch doesn't match is marked skipped, along with every node only reachable through that branch.
Runs a subgraph once per element of an array, a fixed count, or a numeric range.
- Ports: one in-port, two out-ports labeled body (the repeated subgraph) and done (what runs once after every iteration finishes).
- Settings: source (expression / count / range),
maxIterationscap, concurrency, per-iteration delay, continue-on-error.
Full details, including the loop variables ({{loopName.item}}, .index, .count) and aggregates available after done, are on the Loops page.
A fixed pause — nothing more.
- Ports: one in-port, one out-port (no named ports, no
{{...}}references). - Settings: wait time in milliseconds.
A delay node never fails; after the wait elapses it passes and its outgoing edge activates. Useful for rate-limited APIs or waiting out an eventual-consistency window between a write and a read.
Sub-flow
Section titled “Sub-flow”Calls another saved flow as a nested step — the composition tool for keeping a big journey out of a single sprawling canvas.
- Ports: one in-port, one out-port. The node fails (and downstream is skipped) if any node inside the called flow fails.
- Settings: the target flow, and input mappings — name/value-expression pairs that become variables inside the child flow.
The child runs isolated: it cannot see the parent's node outputs, only what you explicitly map in. Its own extractions come back out as {{subflowNode.outputs.childNode.extraction}}. Full details, including recursion protection, on the Sub-flows page.
Script
Section titled “Script”Runs a JavaScript snippet using the same pro.* API as Scripting.
- Ports: one in-port, one out-port.
- Settings: the script body (a multiline code editor).
Any variable you set with pro.environment.set(...) becomes one of the node's outputs, readable downstream the same way an extraction is. console.log output shows up in the run report. See Scripting in Flows for the full picture, including the headless-CLI limitation.