Skip to main content
A Journey is an ordered sequence of API requests that proves a workflow behaves as intended. It is the central organizing unit in Reqflo: you build it, run it, share it, and use it to collect evidence that your API works end-to-end.

​
When to use it

Think of a Journey whenever you need to verify a multi-step API flow — anything from a single authenticated request to a full user onboarding sequence spanning five services. If you can describe the flow as “do A, then B, check C,” a Journey captures that. Journeys are useful for:
  • Automated API testing in CI or scheduled runs.
  • Exploratory workflows where you need to walk through an API to reach a specific state.
  • Operational runbooks that guide support teams through reproducible steps.
  • Evidence collection to prove that a flow works (or doesn’t) in a given environment.

​
Key concepts

Steps are the individual units of work within a journey. Each step today is an HTTP request step. The journey defines the order steps run, how they share data, and what assertions each step must pass. Build mode is where you define the journey. The main canvas holds steps and acceptance criteria. Side panels configure Values, Coverage, Run check, Details, and Access. Two editing views — Visual and YAML — describe the same journey structure. You can switch between them without losing work. Base template and overlays — every journey starts from a base template. You can layer overlays on top to create variants, customer-specific flows, or edge-case configurations without losing the connection to the original. Acceptance criteria are attached at the journey level. They define what the journey is supposed to prove and feed into the Coverage view.

​
How it works

  1. You create a journey in Build mode and add steps from the request template library.
  2. You configure how each step gets its values (run inputs, variables, step outputs, and so on).
  3. You add assertions to steps to define what success looks like.
  4. When you run the journey, Reqflo compiles it into a build artifact and executes it — locally via the CLI, or in the cloud via the Cloud Runner.
  5. Results show per-step status, assertion outcomes, derived values, and evidence.

​
Examples

A typical journey might look like: 
1. POST /auth/token            → capture access_token from response
2. POST /orders                → use access_token, capture order_id
3. GET  /orders/{order_id}     → assert order.status == "pending"
Step 1 produces an output that step 2 consumes. Step 3 uses the order_id from step 2. Each step can have its own assertions. The journey as a whole either passes or fails based on those assertions.