Skip to content

Flows

Testing a real API journey almost never means firing one request. It means: log in, take the token from the response, use it on the next call, check that call returned what you expected, maybe loop over a list, maybe branch on a status code. Doing that by hand in Composer means re-typing headers and copy-pasting values between tabs, every single time you want to re-run it.

Flows turn that journey into a diagram you build once and run forever. Drag requests onto a canvas, wire them together, tell Probe which values to carry from one response into the next request, and add assertions to check what came back. Hit Run and watch each node light up as it executes. Save the flow, share it with a teammate as a file, or run it headlessly in CI.

A Flow open on the canvas: a Start node connects to a Login request node, which extracts a token and feeds a Get Profile request node, with the run report panel docked at the bottom showing pass/fail status for each node

A flow is a small graph:

  • Nodes are steps — an HTTP request, a branch, a loop, a pause, a call into another flow, or a script.
  • Edges are the order nodes run in. Drag from one node's out-port to another node's in-port to connect them.
  • Variables carry data along the edges. Name an extraction on a request node (e.g. pull token out of the login response body), and any downstream node can reference it as {{login.outputs.token}} — in a URL, a header, or a body field.

That's the whole model. There's no separate "test script" language to learn for the common case — extractions and assertions are just fields you fill in on a node, and they show up right there on the canvas.

Flows share the request-building side of Probe with Composer. Click the API Client icon at the top of the sidebar to switch into Composer view, then look for the FLOWS section in the sidebar, below your collections. Click + to create a new flow, or click an existing one to open (or refocus) its tab.

Because a flow's request nodes reference real requests from your Composer collections, a request node sends that request's headers, Params rows and body, plus any cookies set earlier in the same run (a response's Set-Cookie); the Cookies tab of the saved request is not sent, and the headless CLI sends no cookies. It does not apply the request's or collection's auth, the collection's default headers, the GraphQL envelope or form-data and binary bodies, so set Authorization in the node's headers.

Diagram of a flow tab, top to bottom. The run toolbar has the Run button, the add-node buttons (Condition, Loop, Delay, Sub-flow, Script) and Auto-layout, the active environment (Dev), a 3 passed chip, the run time 240ms and a help button. The canvas shows Start wired to a POST Login request node, wired to a GET Get Profile request node. The run report below reads Run finished · 3 nodes · 240ms, with one row per node: Start; Login, status 200, 142ms, 1 output; Get Profile, status 200, 98ms, 2/2 assertions.Diagram of a flow tab, top to bottom. The run toolbar has the Run button, the add-node buttons (Condition, Loop, Delay, Sub-flow, Script) and Auto-layout, the active environment (Dev), a 3 passed chip, the run time 240ms and a help button. The canvas shows Start wired to a POST Login request node, wired to a GET Get Profile request node. The run report below reads Run finished · 3 nodes · 240ms, with one row per node: Start; Login, status 200, 142ms, 1 output; Get Profile, status 200, 98ms, 2/2 assertions.

Requests get dragged onto the canvas straight from the Composer collection tree in the sidebar. Selecting a node opens its inspector (config: extractions, assertions, condition expression, loop source, etc.) — the inspector isn't drawn above: it docks on the right of the canvas while any node other than Start is selected.

Every flow is built from seven kinds of node — Start, Request, Condition, Loop, Delay, Sub-flow, and Script. See Node Types for what each one does, its ports, and its settings.