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. The editor shows inherited values in a read-only panel, with the folder each one comes from.
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. im.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}}

The other protocols resolve the same way: WebSocket and gRPC substitute their endpoint and headers/metadata at connect time, and every outgoing frame or message at send time — so a payload can carry {{token}}, or a fresh {{$guid}} per message.

Seeing what will resolve

Every field that takes a variable highlights its {{name}} tokens as you type — green when the name resolves in the current scope, red when nothing will replace it. That includes the request body (raw, GraphQL query and variables), the gRPC message, MCP tool arguments, and the WebSocket send box, as well as the URL, headers, query and auth fields. Hover a token to see the value it will resolve to; secrets show as bullets rather than their contents, and an ƒx value shows its expression.

A red token is the quickest way to catch a typo or a variable that belongs to a different environment — it’s exactly what will be sent verbatim, since unresolved tokens are left untouched.

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 an encrypted vault on your device — unlocked by 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 im.variables.get(...). Use them when a value needs to be computed fresh on every send. Errors in an ƒx expression are surfaced inline.

Auditing variables

As your workspace grows, it is easy to accumulate stale variables. The Audit feature helps you keep your environments clean. It scans your workspace to find:

• Unused variables: Defined in the environment but never referenced.
• Unset variables: Referenced by requests but missing from the environment.
• Duplicate variables: Defined multiple times across environments with identical values.

You can access the audit tool to quickly review and clean up your variable usage.