Skip to main content
A request template declares every variable part of the request as a template value: path parameters, query parameters, header values, and body fields that will differ between runs. Declaring them in the template is what lets journeys and steps know what to ask for — and what to surface in the Values panel.

When to use it

Read this when you’re defining a new template and need to specify what inputs it requires, or when you’re configuring a step and want to understand why a particular value is showing up in the values panel.

Key concepts

  • Declaration — each template value has a name, a location (path, query, header, or body), and a required flag. This is the contract the template exposes to any step that uses it.
  • Recommended configuration — a template can suggest how a value should typically be sourced (e.g., “this should come from a run input” or “this is usually a secret reference”). Journeys can follow or override the recommendation.
  • Example values — templates can include example values for documentation and test-data generation. See Examples and Faker values.
  • Description — a short explanation of what each value means, shown in the values panel, the step picker, and runbooks.
Template values are separate from how a journey actually supplies them. The template says “I need a paymentId in the path.” The step says “I’ll get it from the previous step’s output.” That separation is what makes templates reusable across completely different journeys.

How it works

When you declare a template value, you specify:
FieldDescription
nameThe parameter name as it appears in the URL pattern or body
inWhere it goes: path, query, header, or body
requiredWhether the step will block without it
descriptionHuman-readable explanation shown in the UI
recommended_source(Optional) A suggested source type for configuration
exampleA representative value for documentation and Faker generation
When a step references this template, the Values panel surfaces each declared value and lets you configure its source for that journey. Required values without a configured source appear as errors in Run check. A recommended source is a hint, not a constraint. It tells the person configuring the step where the value is typically expected to come from:
  • run_input — the caller provides it at runtime; good for IDs you don’t know ahead of time.
  • variable — defined as a journey-level variable; good for shared configuration.
  • step_output — taken from a previous step’s response; good for chained requests.
  • secret — should be a secret reference, never a raw value; good for tokens and credentials.
  • environment — comes from the selected environment; good for base URLs or service config.
  • hard_coded — a fixed value that doesn’t change between runs.

Examples

Declaring a path parameter
values:
  - name: userId
    in: path
    required: true
    description: The ID of the user whose profile you are fetching.
    recommended_source: step_output
    example: usr_01HXYZ
Declaring an authorization header value
values:
  - name: Authorization
    in: header
    required: true
    description: Bearer token for authenticating the request.
    recommended_source: secret
Declaring optional query parameters
values:
  - name: limit
    in: query
    required: false
    description: Maximum number of results to return. Defaults to 20.
    example: 20
  - name: cursor
    in: query
    required: false
    description: Pagination cursor from the previous response.
    recommended_source: step_output
Write descriptions as if you’re explaining the field to someone who has never seen this API. They show up in the values panel, in runbooks, and anywhere a step is being configured — clear descriptions save a lot of back-and-forth later.

HTTP request templates

The full shape of an HTTP request template.

Examples and Faker values

How to attach example and generated values to template fields.

Step values

How steps configure sources for each declared value.

Values overview

The full value resolution model across journeys.