03 / Repeat the proof
Turn repeatable API checks into workflows your team can run again
Build multi-step API workflows with variables, assertions, branching, and evidence—without scattering critical checks across shell history and one-off scripts.
- 01POST /session201
- 02GET /cart/{{id}}200
- 03assert total < limitPASS
variables carried forward ✓
Working reference
What goes in, what comes out, and what the result can prove.
Concrete artifact
Carry an identifier between dependent requests
POST /orders → save $.id as orderId
GET /orders/{{orderId}} → expect 200
assert $.status == "created"Review sequence
Three checks before the result becomes a decision.
Variable resolution
Confirm every referenced value exists before the dependent step.
Assertions
Check status, headers, payload shape and timing—not only HTTP 200.
Failure position
Report the first divergent step with its request and response.
Limits
What this workflow does not prove.
- A passing workflow proves only the configured examples and assertions.
- Secrets belong in scoped environment variables, not exported workflow JSON.
- Retry behavior must be explicit or a transient failure can hide a defect.
Questions worth answering
Before you put it into a real workflow.
Can later steps use earlier responses?
Yes. Extract values from a response and use them as variables in subsequent requests.
Does automation require code?
No for common request flows and assertions. Export and API options are available when code or CI integration is appropriate.
Can I inspect a failed step?
Yes. Runs retain request, response, assertion, and timing context at the step level.
Next move
Start with one concrete API problem.
Keep the first step small. Move into a workspace when the result deserves to be saved, repeated, or shared.