Skip to main content
An HTTP request template captures everything that defines the shape of a request to a specific endpoint. It’s the single source of truth for that request’s structure — journeys and steps add the execution context (values, sequencing, assertions) on top of it.

​
When to use it

Understand this page when you’re creating or editing templates in the library, reviewing what a step will actually send, or debugging a request that isn’t behaving as expected.

​
Key concepts

FieldPurpose
methodHTTP verb: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS
urlThe URL pattern, including path parameter placeholders (e.g., /v2/payments/:paymentId)
headersKey/value pairs sent with every request using this template
bodyRequest body definition — shape, content type, and field declarations
queryQuery parameter declarations
nameHuman-readable label shown in the library and step picker
descriptionOptional — explains the purpose of this endpoint
tagsUsed for organizing and filtering in the library
Path parameters, query parameters, header values, and body fields that vary between runs are declared as template values (see Template values). Static parts of the request — a fixed Content-Type header, a constant path segment — are defined directly in the template.

​
How it works

A template separates the fixed parts of a request from the variable parts:
  • Fixed — literal values baked into the template. For example: Content-Type: application/json, or a base path like /v2/payments.
  • Variable — declared values that callers must supply. For example, a :paymentId path parameter or an amount body field.
When a step is configured in a journey, the journey resolves each declared value from its configured source (run inputs, variables, step outputs, environment values, etc.) and combines them with the fixed parts to produce the final outgoing request.

​
Examples

A simple GET template 
name: Get payment
method: GET
url: /v2/payments/:paymentId
tags:
  - payments
headers:
  Accept: application/json
values:
  - name: paymentId
    in: path
    required: true
    description: The ID of the payment to retrieve
A POST template with a JSON body 
name: Create payment
method: POST
url: /v2/payments
tags:
  - payments
headers:
  Content-Type: application/json
  Accept: application/json
body:
  type: json
  schema:
    amount:
      type: number
      required: true
    currency:
      type: string
      required: true
      example: USD
    source_id:
      type: string
      required: true
values:
  - name: amount
    in: body
    required: true
  - name: currency
    in: body
    required: true
  - name: source_id
    in: body
    required: true
A PATCH template with mixed parameter types 
name: Update payment metadata
method: PATCH
url: /v2/payments/:paymentId/metadata
tags:
  - payments
headers:
  Content-Type: application/json
values:
  - name: paymentId
    in: path
    required: true
  - name: note
    in: body
    required: false
    description: Optional note to attach to the payment
Keep templates focused on a single endpoint. If you need to call the same URL with meaningfully different body shapes, consider separate templates with descriptive names — it makes the library easier to navigate and steps easier to understand at a glance.

Template values

How templates declare the values they need and recommend configuration.

Template assertions

Assertions that apply whenever this template is used.

Examples and Faker values

Default and generated values for previewing and testing.

Request template library

Where templates live and how to manage them.