Skip to main content
A journey is the central object in Reqflo. It captures everything needed to define, execute, and track an API workflow: its metadata, steps, value configuration, access controls, and versioning. This page documents the journey object’s fields as they appear across the Details, Build, and Values panels.

​
Metadata fields

These fields describe and identify the journey. They are configured in the Details panel and appear in the YAML under journey.*.
FieldDescription
nameHuman-readable journey name. Shown in lists, CLI output, and run reports.
descriptionShort explanation of what the journey does and why it exists.
ownerTeam or user responsible for the journey. Used for filtering and access management.
tagsFreeform labels (e.g. smoke, payments, regression) for discovery and grouping.
versionSemantic version string tracking the journey’s release state (e.g. 1.0.0).

​
Structure fields

These fields define the journey’s execution structure.
FieldDescription
base_templateThe base request template this journey derives from. Sets the foundational request shape.
overlaysNamed overlays that modify the base template without replacing it. Useful for variants, edge cases, or customer-specific flows.
stepsThe ordered list of steps that make up the journey. Each step references a request template and declares how values are supplied.
inputsRun inputs declared for the journey — values that must be supplied (or defaulted) at run time.
variablesVariables available throughout the journey, with configurable sources (environment, “me”, preset, hard-coded, or manually set).

​
Access fields

Access is configured in the Access panel and controls who can interact with the journey.
FieldDescription
ownersUsers or teams who can manage access and settings.
editorsUsers or teams who can update the journey definition.
viewersUsers or teams who can inspect the journey but not modify it.
privateWhen true, the journey is hidden from users who are not explicitly listed. Default visibility is read-only for everyone.

​
Base templates and overlays

Every journey has a base template that defines its starting request structure. On top of that, you can add any number of overlays — modifications that layer over the base without breaking the relationship to it. 
journey:
  base_template: "checkout-flow-v3"
  overlays:
    - "guest-checkout"
    - "expired-payment-method"
Overlays are useful for testing variants (happy path vs. edge case), customer-specific configurations, or modified behaviors that share the same core flow.

​
Versioning

Journey versions are managed through the Details panel and reflected in the version field. Build artifacts are tied to a specific version, making cloud runs reproducible and auditable. See Versioning and artifacts for more on how versions relate to build artifacts.

​
Steps summary

A journey must contain at least one step. Steps are ordered and executed sequentially. Each step:
  • References a request template from the template library
  • Declares how each required value is supplied (run input, variable, step output, environment value, secret reference, hard-coded value, or “me” value)
  • Optionally defines assertions to validate the response
See the YAML schema for the full step field reference, and Step types for the list of supported and planned step types.