Building flows

A flow is a chain of API steps you can run on demand — from the UI, the CLI, the API, or CI. You build flows on a visual canvas: drag nodes from the palette, connect them with edges, then press Run flow. Each run is recorded as an execution in Run history.

Node types

The palette has exactly three node types:

Node	What it does
Request	Sends an HTTP request. Configure method, URL, headers, and body. Attach outputs and assertions to its response.
Delay	Waits for a fixed duration before the next node runs. Useful when the API you are testing settles asynchronously.
Module	Runs another flow as a child execution step. This is flow reuse: pass values in with input bindings, read values back with output bindings.

A checkout-smoke flow for a payments API might look like:

1. POST /auth/token — Request node, asserts statusCode equals 200
2. POST /payments — Request node, extracts $.id into payment_id
3. Delay 2s — Delay node, waits for settlement
4. verify-refund — Module node that runs a shared refund-check flow

Edges and run conditions

Edges connect nodes along success or error paths, so a failing request can route to different downstream steps than a passing one.

Each node also has a run_when condition:

• on_success (default) — the node runs only when its upstream path succeeded.
• always — the node runs even after an upstream failure. Use this for cleanup steps, such as deleting the test payment a failed run left behind.

Nodes that do not run are marked skipped, and the execution records a skip_reason plus any missing_inputs, so you can see exactly why a step was bypassed.

Variables

Reference values anywhere in a request with {{double_brace}} syntax:

• Outputs extracted from earlier nodes, such as {{payment_id}}
• Environment variables like {{BASE_URL}} and {{API_TOKEN}}
• Dynamic variables like {{$uuid}} for generated test data

Build from the CLI

Everything on the canvas can also be scripted with the CLI. Add each node type with echopoint flows node add:

# Request node
echopoint flows node add <flow-id> --type request --name "Create payment" \
  --method POST --url "{{BASE_URL}}/payments" \
  --headers '{"Authorization": "Bearer {{API_TOKEN}}"}' \
  --body '{"amount": 4200, "currency": "eur"}'

# Delay node (duration in milliseconds)
echopoint flows node add <flow-id> --type delay --name "Wait for settlement" \
  --duration 2000

# Module node: run another flow as a child step
echopoint flows node add <flow-id> --type module --name "verify-refund" \
  --flow-id <child-flow-id> \
  --input payment_id={{payment_id}} \
  --output refund_status=refund_status

Connect nodes with edges, or let --after wire the edge for you when adding a node:

echopoint flows edge add <flow-id> --from create-payment --to verify-refund

# A cleanup step that runs even when upstream failed
echopoint flows node add <flow-id> --id cleanup --type request \
  --run-when always --after verify-refund \
  --name "Delete test payment" --method DELETE \
  --url "{{BASE_URL}}/payments/{{payment_id}}"

Validate and export

Before running a flow in CI, check that its structure is sound — every referenced node exists, bindings resolve, edges connect real nodes:

echopoint flows validate <flow-id>

Export the full flow definition as JSON to review it or keep a copy alongside your code:

echopoint flows export <flow-id>

Next steps

• Outputs & assertions — extract response values and assert on them
• Dynamic variables — 69 built-in test-data generators
• Tags & search — group flows into suites like smoke
• Versions & publishing — immutable snapshots and version pinning
• Echopoint AI — ask the copilot to inspect or modify the flow
• Executions & live runs — what happens when you press Run flow