Variables & environments

Write {{variable}} anywhere in a URL, header, query parameter, body or auth field and Tiger replaces it with the value from the active environment before sending. Switching environments changes every value at once - no edits to individual requests required.

How interpolation works

When you send a request Tiger reads the active environment, builds a flat map of variable names to their values, and then substitutes every {{name}} token it finds in the request's URL, headers, query parameters, body text and auth fields. Unknown tokens - names that do not exist in the active environment - are left untouched so Tiger can highlight them as unresolved in the UI.

Substitution happens recursively up to ten levels deep, which means a variable's value can itself reference another variable:

vars {
  api:     /v2
  baseUrl: https://api.example.com{{api}}
}

Here {{baseUrl}} in a request URL resolves to https://api.example.com/v2. Circular references stop expanding after the depth limit is reached, leaving the remaining token literal rather than looping forever.

Environments

An environment is a named set of variables stored as a .tiger file inside the collection's environments/ subfolder. Each collection can have as many environments as you need - for example dev, staging and production.

File format

An environment file has a meta block that gives it its display name and a vars block that lists key/value pairs, one per line:

meta {
  name: dev
}

vars {
  baseUrl: https://api.test.example.com
  apiVersion: v2
  timeout: 5000
}

Secret variables (see below) go in a separate vars:secret block in the same file:

meta {
  name: dev
}

vars {
  baseUrl: https://api.test.example.com
  apiVersion: v2
}

vars:secret {
  apiKey: sk-dev-abc123
  clientSecret: dev-secret-xyz
}

The file is plain text and safe to commit. Secret values are stored as-is - they are only masked in the Tiger UI, not encrypted on disk. Keep this in mind for production credentials; the common pattern is to keep a production.tiger environment out of version control via .gitignore while committing the others.

Folder layout

A typical collection on disk looks like this:

my-api/
  collection.tiger
  create-post.tiger
  get-posts.tiger
  environments/
    dev.tiger
    staging.tiger
    production.tiger   # add to .gitignore if it has real secrets

Switching the active environment

The environment picker sits in the top-right corner of the Tiger window. Click it to open a dropdown of every environment in the current collection's environments/ folder. Selecting one makes it active immediately - the URL bar updates to reflect the resolved value of any variables it contains, and the next send uses the new values.

You can also have no active environment. In that state, all {{variable}} tokens remain unresolved and Tiger shows an unresolved- variable warning under the URL bar.

Disabling individual variables

Prefix any variable line with ~ to disable it without deleting it. A disabled variable is excluded from the interpolation map; any request that references its name treats it as unresolved:

vars {
  baseUrl: https://api.example.com
  ~debugHeader: 1
}

This mirrors the same ~ convention used to disable individual request headers and query parameters.

Secret (hidden) variables

Variables in a vars:secret block are marked as secret. In the Tiger UI their values are masked with dots rather than shown in plain text. They are otherwise normal variables: they interpolate into requests the same way, appear in the environment editor (masked), and are serialised into the same file.

vars:secret {
  apiKey: sk-live-...
  clientSecret: s3cr3t
}

Dynamic variables

Tiger provides four built-in variables prefixed with $. They are resolved at send time and re-evaluated on every occurrence - each {{$uuid}} in the same request gets a different value:

Dynamic variables do not need to be defined in any environment - they work whether an environment is active or not. The findMissingVars check in Tiger also skips $-prefixed tokens, so they never appear as unresolved warnings.

A practical use: generate a unique correlation ID on every send without any setup:

post {
  url: {{baseUrl}}/orders
}

headers {
  X-Request-Id: {{$uuid}}
  X-Sent-At:   {{$isoTimestamp}}
}

Where variables can appear

Interpolation runs on every text field that Tiger sends over the wire. There is no field that is off-limits:

• URL - including the scheme, host, path segments and any inline query string.
• Query parameters - both the name column and the value column of each row.
• Headers - the value column of each header row (not the header name).
• Body - any body type: JSON, XML, plain text, form-encoded, GraphQL query and variables, multipart field values.
• Auth fields - Bearer token, Basic username and password, API key value, OAuth 2.0 token URL, client ID, client secret and scope.

Unresolved-variable warning

If the URL bar contains a token that is not present in the active environment (or if no environment is active), Tiger displays a yellow warning strip directly below the URL bar listing the missing names. The request can still be sent - Tiger passes the literal {{token}} string - but the warning helps you catch missing configuration before a confusing 404 or 401.

https://{{baseUrl}}/users    ← warns: baseUrl is not defined

Variables set by scripts

Pre-request and post-response scripts can set variables at runtime using the tiger.setVariable(name, value) API. A value set this way is written into the active environment for the remainder of the session and is available to the next request in a collection runner run. This is how request chaining via response captures works under the hood.

// post-response script: extract a token and store it
const body = JSON.parse(tiger.response.body)
tiger.setVariable('authToken', body.access_token)

A complementary lower-level mechanism is the capture block in the .tiger file format, which does the same thing declaratively without writing a script. See Request chaining & captures for the full picture.

Full environment file reference

meta {
  name: staging
}

vars {
  baseUrl:    https://staging.example.com
  apiVersion: v2
  pageSize:   50
  ~debugMode: true    # disabled; won't be substituted
}

vars:secret {
  apiKey:       sk-staging-abc123
  clientSecret: stg-secret-xyz
}

Field-by-field breakdown:

• meta.name - the display name shown in the environment picker.
• vars { … } - plain (visible) variables, one key: value pair per line.
• vars:secret { … } - masked variables; values are hidden in the Tiger UI but stored as plain text on disk.
• A ~ prefix on any line disables that variable without removing it.

Related pages