Variables

Variables keep the instructions stable while the specifics change. They are a plain key-value map on the routine, substituted into the instructions immediately before each run.

Syntax

Write a placeholder in the instructions:

Audit the repository {{repository}} for changes merged since last Monday.
Report in {{reportingCurrency}}.

Then set the values on the routine:

{
  "repository": "acme/web-app",
  "reportingCurrency": "USD"
}

Keys may contain letters, digits, _, ., and -. Whitespace inside the braces is ignored, so {{ repository }} and {{repository}} are the same placeholder.

Every placeholder needs a value

Saving a routine whose instructions reference a placeholder with nothing to render is refused with 400 missing_variables, and details.variables names the keys. This covers a value that is absent, blank, or not a string or number — including a typo, which reads as a placeholder nobody filled in:

{
  "error": {
    "code": "missing_variables",
    "details": { "variables": ["staleDays"] }
  }
}

The composer says the same thing beside the variables box before you save.

Routines saved before this rule existed keep running: the guard applies to writes, not to stored routines, so a routine that already holds no value for a key can still be renamed, rescheduled, and run. Its placeholder still renders as an empty string, and the next edit of its instructions or variables asks for the value.

Substitution rules

Only the instructions are rendered. The routine name, description, and webhook configuration are not templated.

Naming

Use the same casing everywhere and prefer names that read as nouns in a sentence: repository, siteUrl, reportingWindow, campaign, reportingCurrency. Templates in the product follow this convention, and their variables carry a label, a description, whether they are required, and an example.

Changing a variable

Updating variables is a material configuration change: the routine returns to draft and needs a fresh manual proof before it can be scheduled again.

This matters for routines whose variable rotates — a weekly blog topic, for example. Plan for a proof run each time, or drive the rotation from a variable that describes the rule ("this week's highest-traffic page") rather than the value itself.

What not to put in a variable

Never put credentials, tokens, or API keys in variables. They are substituted directly into the prompt, which means the model sees them and they can reach a tool call.

Credentials belong in connection headers, where they are encrypted at rest and resolved server-side at call time. See Connections.