Environments and variables

Creating dev and prod environments, using {{base}} and {{token}} in a request, and switching between them. Narrated, with sound. The dark and light versions follow the site's theme.

Environments hold named variables you reference as {{name}}.

Where they apply

In a request’s endpoint, WS endpoint, headers (names and values, which are also the WebSocket connection params) and variables. They are not applied to the query text.

Create and use one

1. Open the environment select in the request bar and choose Manage….
2. New environment, give it a name, add variables.
3. Mark a variable secret to mask it.
4. Use {{name}} in the endpoint, headers or variables, then pick the active environment in the request bar.

Globals are variables that apply whichever environment is active. A variable in the active environment wins over a global of the same name.

Where values go

• In the Variables editor, a placeholder inside a JSON string is filled with the value escaped, so "{{name}}" stays valid whatever it contains.
• Outside a string the value is inserted as is, so {"limit": {{pageSize}}} can become a number.
• A value is never scanned for placeholders itself, and \{{ writes a literal {{.

Built-ins

{{$timestamp}} (epoch ms), {{$isoTimestamp}} and {{$uuid}}, fresh for each run.

Missing variables

A run that uses a name nothing defines is blocked. The error and a red Missing: … chip list the names; click the chip to define one. Editors underline missing names and tint defined ones. Hovering shows the value, never a secret’s.

Secrets

History, the Traffic list and exports never contain a resolved value: history keeps the {{placeholders}}, and Export writes secret values as empty strings unless you tick Include secrets.

Caution

A secret placed in the endpoint itself ends up in the local schema cache. Put secrets in headers instead.

Palette commands

Environment: <name>, Environment: none, Switch environment (next one) and Manage environments.