Outputs & assertions

Request nodes can do two things with a response: extract values into named outputs for later nodes, and assert that values match what you expect. Both are built on the same extractors.

Extractors

Extractor	Reads	Example
`json_path`	A value from a JSON body, using RFC 9535 JSONPath	`$.id`, `$.data[0].status`
`xml_path`	A value from an XML body, using XPath	`/order/status`
`status_code`	The HTTP status code	`201`
`header`	A named response header	`Content-Type`
`body`	The raw response body	full text

The table above describes the runtime extractor set. The incremental CLI command flows node output add accepts json_path, status_code, body, and header; it does not author xml_path outputs. Use the canvas or a full flow definition for runtime features outside the CLI command subset.

Outputs

An output gives an extracted value a name that later nodes can reference with {{double_brace}} syntax. On a node with ID create_payment, extract the payment ID after POST /payments, then use {{create_payment.payment_id}} in the next request. Outputs use {{node_id.output_name}}; bare names refer to input or environment variables:

echopoint flows node output add <flow-id> create_payment \
  --name payment_id --extractor json_path --path "$.id"

# Status code and header outputs work the same way
echopoint flows node output add <flow-id> <node-id> \
  --name status --extractor status_code
echopoint flows node output add <flow-id> <node-id> \
  --name content_type --extractor header --header-name "Content-Type"

Assertion operators

An assertion pairs an extractor with one of 14 operators and an expected value:

Operator	Passes when the actual value…
`equals`	exactly equals the expected value
`not_equals`	differs from the expected value
`contains`	contains the expected value as a substring
`not_contains`	does not contain the expected value
`starts_with`	begins with the expected value
`ends_with`	ends with the expected value
`regex`	matches the expected regular expression
`empty`	is empty (no expected value needed)
`not_empty`	is not empty (no expected value needed)
`greater_than`	is numerically greater than the expected value
`less_than`	is numerically less than the expected value
`greater_than_or_equal`	is numerically greater than or equal
`less_than_or_equal`	is numerically less than or equal
`between`	falls within the expected numeric range

For CLI v1.7.0, flows node assertion add accepts the snake_case operators above except between. It accepts status_code, json_path, body, and header extractors. It does not accept xml_path. Use the canvas or full flow definitions for those runtime features.

Add supported assertions from the CLI with flows node assertion add:

# Assert the payment was created
echopoint flows node assertion add <flow-id> <node-id> \
  --extractor status_code --operator equals --value "201"

# Assert the payment succeeded
echopoint flows node assertion add <flow-id> <node-id> \
  --extractor json_path --path "$.status" --operator equals --value "succeeded"

# Assert the body mentions the currency
echopoint flows node assertion add <flow-id> <node-id> \
  --extractor body --operator contains --value "eur"

Every assertion is recorded — pass or fail

Each assertion result is stored with three fields: expected, actual, and passed. This happens on passing runs too, not just failures. When a run goes green you can still open any node and confirm what the API actually returned — useful when an equals assertion passes for the wrong reason, or when you are reviewing a run someone else launched.

Where results show up

On the canvas: after a run, each node shows its result. Open a node to see its assertion results with expected vs actual values side by side.
In run history: every execution keeps the full set of per-node assertion results, so you can compare what a flow returned across runs.

Next steps

Building flows — nodes, edges, and the canvas
Dynamic variables — generate test data for request bodies
Executions & live runs — reading node results and run history
CLI — full command reference