Environments & variables

Variables let you parameterise requests — base URLs, tokens, IDs — and swap them out per environment without editing every request.

Variable scopes

When a request is sent, {{name}} references resolve against a layered set of scopes, from broadest to most specific:

1. Global — workspace-wide values.
2. Folder — values set on an ancestor folder’s settings.yaml, inherited by everything beneath it. A nearer folder overrides a farther one.
3. Environment — values from the active environment.
4. Request — values defined on the request itself.
5. Runtime — values set during execution by a script, e.g. pm.environment.set(...).

More specific scopes win, so a request-local userId overrides an environment one.

Variable substitution

{{name}} placeholders are resolved at send time across the URL, query, headers, body, auth fields, and TLS paths. For example:

GET {{baseUrl}}/users/{{userId}}
Authorization: Bearer {{token}}

Environments

An environment is a named set of variables — typically one per target (local, staging, production). Switch the active environment from the sidebar; the active one is marked, and each environment carries a colour for quick visual orientation. Environments are stored as files in the workspace and can be cloned.

Secrets (passwords, tokens, keys) are stored in your OS keychain rather than in the workspace files. See TLS & certificates and the storage format for how secret references work.

Dynamic tokens

Postman-compatible dynamic values are available inline:

ƒx scripted values

Beyond static values, a variable’s value can be a small JavaScript expression (an ƒx value), evaluated at resolve time. Scripted values can call helpers like guid(), datetime(), timestamp(), randomInt(), and randomBetween(), and read other variables with pm.variables.get(...). Use them when a value needs to be computed fresh on every send. Errors in an ƒx expression are surfaced inline.