Projects

Variables

Variables keep configuration out of your requests. Instead of hard-coding URLs, tokens, and IDs, you reference {{variableName}} and let the active environment supply the value — so the same test or monitor runs against dev, staging, and production unchanged.

Scopes and resolution order

Variables exist in three scopes:

Scope Where it's managed Who sees it
Organization Settings → Variables (Organization Variables) Available across all projects in your organization.
Project (environment) The Variables tab of each environment Shared with everyone in the project; each environment has its own set.
Personal The My Variables tab of each environment Only you — ideal for personal tokens and local overrides.

On key conflicts, the more specific scope wins: Personal > Project > Organization. Keys are compared case-insensitively.

The Resolved tab of an environment shows the final merged set — each variable with its value (secrets masked), a Secret/Plain type badge, and a Source badge (Org, Project, or Personal) telling you which scope supplied it.

The Resolved tab showing merged variables with scope badges

Organization variables also appear as read-only rows (marked Org) inside each environment's Variables tab. Double-click one to override it at the environment level — the key stays fixed, you supply the environment-specific value, and the row gets an Override badge.

Editing variables

Open an environment from the Projects page sidebar (or use Edit Variables in the header's environment switcher). The variable table edits inline:

  • Add variable (+) adds a row; double-click any row to edit it. Each variable has a Key, Value, Secret checkbox, and optional Description.
  • Keys must use letters, digits, and underscores, and must not start with a digit. Duplicate keys are flagged and not saved.
  • Keyboard-friendly: Enter commits, Tab moves through fields and onto the next row, and the up/down arrows jump between rows. Tabbing past the last row starts a new one.
  • Drag the grip handle to reorder rows.
  • Right-click a row for Edit, Duplicate (secrets are duplicated without their value), and Delete.
  • Changes auto-save — a brief "Saving..." indicator appears next to the heading.
The environment variables table with a row in inline edit mode

Secrets

Mark a variable as Secret to store it encrypted and mask it (••••••••) everywhere — tables, previews, and exports. To see a secret's value, click the eye icon (Reveal value) while editing; reveals fetch the decrypted value on demand. The audit log records reveals and exports, secrets being created, changed or deleted, and — as Unsecured — a variable losing its Secret flag, which serves its value unmasked from then on. Saving other variables never counts as a change to a secret you did not touch.

If a variable's key looks sensitive (e.g. contains "token" or "password") but isn't marked secret, a dismissible banner suggests marking it: "You have variables that may contain sensitive data … Consider marking them as secrets for encryption and masking."

Secret values are deliberately never copied when you duplicate a variable, copy variables into a new environment, or copy an auth configuration — only the structure travels; you re-enter the secret at the target.

Templates

The Apply template button adds a predefined variable set, skipping keys you already have:

Template Variables
REST API API_BASE_URL, API_KEY (secret), API_TIMEOUT
Authentication (OAuth) AUTH_URL, CLIENT_ID, CLIENT_SECRET (secret), AUTH_AUDIENCE, BEARER_TOKEN (secret), REDIRECT_URI
Database DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD (secret)

Importing variables

The import button in the table toolbar opens a three-step dialog:

  1. Import Variables — choose the format (.env or JSON) and paste the content. In .env format, a # comment line above a variable becomes its description.
  2. Preview Import — review the parsed variables. Keys that look like secrets are auto-detected (marked auto) and will be encrypted; check or uncheck the Secret box per variable. Choose a Duplicate strategy: Skip duplicates, Overwrite existing, or Error on duplicates.
  3. Import Complete — a summary of created, updated, skipped, and errored variables.

Exporting variables

The export button downloads the environment's resolved variable set as a file:

  • Format — .env (standard dotenv) or JSON (structured, with metadata).
  • Include secret values — off by default, so secrets are exported masked. Turning it on decrypts secrets into the file; the dialog notes this requires admin permissions, and every exported secret is recorded in the audit log. Treat such files carefully.

Using variables

Reference any resolved variable as {{variableName}} — double curly braces:

  • Test requests — in the URL, headers, or body (e.g. {{baseUrl}}/orders, Authorization: Bearer {{API_TOKEN}}). The request editor's Variables tab lists every available variable, shows which ones the request uses, previews the resolved URL (secrets masked), and warns about unresolved placeholders before you run.
  • Auth configuration — every auth field accepts {{VARIABLE_NAME}}, with autocomplete from the environment's resolved variables. See Project Auth.
  • Monitors — monitor URLs, headers, and request bodies support the same placeholders, resolved from the monitor's environment. See Monitors.

One variable is built in: {{baseUrl}} always resolves to the active environment's Base URL (unless you define your own variable with that key). Requests that use an unresolved variable fail with a clear "unresolved variables" error rather than silently sending the placeholder.

For dynamic values inside test scenarios (fixtures, captures, generated data), see Test Data.

Permissions

  • Environment variables (project scope): editing, importing, and reordering require projects:write — Admins and Owners. Members can view them and use them in requests.
  • Organization variables: managing requires org:manage-governance — Admins and Owners.
  • Personal variables: every member manages their own.