The central unit: journeys
A Journey sequences HTTP requests, validates their results, and proves that a workflow behaves as intended. You can build a journey in the drag-and-drop Visual editor or write it directly in YAML. Either way, the same artifact gets produced and the same runner executes it.Four modes
| Mode | What it’s for |
|---|---|
| Build | Define steps, configure values, map coverage, and set acceptance criteria. |
| Run | Execute the journey and inspect results — status, assertions, derived values, logs, and evidence. |
| Runbook | Guide support or operational users through the journey with structured steps and evidence collection. |
| CLI | Run journeys from a terminal, CI pipeline, or scheduled automation. |
Two editing views
Within Build mode you switch between Visual (canvas-based, drag-and-drop) and YAML (text-based, version-control-friendly). Both views describe the same journey — switching between them is non-destructive.The core nouns
Steps are the units of work inside a journey. Today steps are HTTP request steps that pull from the request template library. Additional step types (connectors, sub-journeys, scripts, set variables, notes, manual checkpoints) are planned. Request templates are the reusable definitions of HTTP request shape. They are the source of truth for how a request is structured; journeys sequence and validate them. Values and variables describe how each step gets the data it needs. Values can be run inputs, declared variables, derived values, step outputs, hard-coded values, environment values, secret references, or user-specific “me” values. Cases are saved value configurations — named snapshots like “Happy path” or “Expired token” that let you replay a specific scenario without re-entering values each time. Environments describe the system target: base URLs, service config, and environment-specific values for sandbox, staging, or production. An environment is not the same as a case — environments describe where you send traffic; cases describe what data you send. Coverage is a journey-level view that maps acceptance criteria and tickets to the journey, surfacing gaps in what the journey proves. Build artifacts are what actually run. Before execution, a journey is compiled into an artifact that captures its structure, steps, value references, assertions, and execution plan. Artifacts make cloud runs repeatable and debuggable.Related pages
Journeys
What a Journey is and why it’s the central organizing unit.
Steps
The units of work inside a journey.
Request templates
Reusable HTTP request definitions that steps pull from.
Values and variables
How steps get the data they need.
Cases
Saved value configurations for repeatable scenarios.
Environments
System targets: sandbox, staging, production.
Secrets
Secret references: selected by name, never displayed.
Assertions
Acceptance criteria that prove intended behavior.
Coverage
Journey-level view of what you’re proving and what’s missing.
Build artifacts
What the runner actually executes.
Runbooks
Guided, support-oriented journey execution.