All sections

Core features

Environments and variables

On this page

A variable in Tetiva comes from the active environment of the current workspace — there is no other source of values. Write {{base_url}} in a URL, a header, a body or an auth field, and substitution replaces it right before the request goes out. If the active environment has no such key, the text is sent verbatim: the server receives a literal {{base_url}} in the URL.

Environments#

An environment is a named set of key/value pairs attached to a workspace. The usual layout is Dev, Staging, Prod — same keys, different values.

The environment selector sits at the right end of the URL bar. A green dot marks the active one, “No Environment” turns substitution off entirely, and “Manage Environments...” opens the management dialog — as does the Environments icon in the left activity bar.

The dialog lists environments on the left and their variables on the right. The circle next to a name activates that environment — only one can be active at a time. Its context menu offers Rename, Duplicate, Export as Postman and Delete, and the download button at the bottom imports a Postman environment file.

Tetiva
v0.17.0
The Manage Environments dialog in Tetiva with local, develop, stage and prod environments and a masked secret in developThe Manage Environments dialog in Tetiva with local, develop, stage and prod environments and a masked secret in develop
A value flagged as a secret renders as dots — the eye in the same row reveals it

Each variable row is an enabled checkbox, a key, a value, a lock toggle for secrets, and a delete button. A disabled variable stays in the list but takes no part in substitution. The new-variable row commits on Enter, on Tab, or when focus leaves the row.

Syntax and where substitution applies#

Substitution matches the {{name}} pattern in URLs, header names and header values, request bodies, auth fields, gRPC metadata, GraphQL queries and GraphQL variables, and in the address of a WebSocket connection.

Three rules are worth learning up front:

  • Whitespace inside the braces matters. Write {{token}}, not {{ token }} — the key looked up is exactly the text between the braces.
  • Substitution is single-pass. If a value itself contains {{other}}, that reference is not expanded on a second pass; it travels as plain text.
  • An unknown variable is not an error. The request is still sent, just with {{...}} inside it. The orange highlight is the only warning you get.

Resolution order#

The order is short, because there is only one level: values come from the enabled variables of the active environment. Tetiva has no collection scope and no global scope — shared values belong in an environment, and per-request values are computed in a pre-request script.

The one thing that overrides the environment is that script. Calling pm.environment.set("token", value) changes the value for the current run: the URL, headers and body are rebuilt with the new value, and auth is applied after the script, so it sees the change too. See Scripting for the full API.

Highlighting, hover peek and drill-through#

Inside CodeMirror editors and auth fields, {{...}} is coloured: the accent colour when the key exists in the active environment, orange when it does not.

Hover for a quarter of a second and a peek appears: the variable name, an Environment or Undefined badge, the current value, and an action link. “Open in Environment →” opens the management dialog, scrolls to the matching row, flashes it, and puts the caret in the value field. “+ Create in Environment” opens the same dialog with the name already filled into the add row.

Cmd/Ctrl+Click on a {{...}} token does the same thing immediately, without waiting for the peek. And typing {{ in an editor pops up completion for the keys of the active environment, each with its value alongside.

Secret variables#

The lock toggle on a row marks a variable as secret. Its value renders as •••••••• in the dialog — the eye button reveals it temporarily — and it is masked in the hover peek and in autocomplete. MCP tools never return it at all.

The flag changes presentation, not storage. The value sits in the local SQLite database as plain text, it is pushed with everything else when sync is on, and it is written to disk when you export the environment in Postman format, tagged with type secret. On the server the workspace data is encrypted at rest (AES-256-GCM, with the master key kept apart from the database), but the service reads it too: it decrypts the data to hand it to your devices. For production credentials the flag protects you from a screenshot or a screen share, not from someone with access to your machine.

Variables written by scripts#

After a request finishes, everything the scripts wrote through pm.environment.set is persisted to the active environment: existing keys are updated, new ones are created enabled and not secret. With no active environment there is nowhere to persist, so the change lives only for that run.

pm.environment.unset applies to the run only — the variable is not removed from the environment. To delete it for good, use the delete button in the management dialog.

What travels between devices is covered in Sync; how variables reach the Authorization header, in Authentication.

updated