Variables & Environments

← Back to contents

Variables let you write a request once and reuse it across hosts, users, and runs. Anywhere you can type — the URL, params, headers, body, or auth fields — you can insert a variable with double-brace syntax: {{name}}.

Using variables

Type {{ in any field to open the typeahead, which lists the variables available in the current scope. Pick one and Rest Hippo inserts it as a highlighted pill:

At send time, every {{name}} is replaced with its resolved value. With Show URL preview on, you can see the resolved URL before you send.

Scopes and resolution order

The same variable name can be defined at several levels. At send time Rest Hippo resolves each {{name}} by walking scopes from most specific to most general and taking the first one that defines the name:

request's folder  ▸  parent folder(s)  ▸  collection environment  ▸  collection Global
(nearest ancestor first) ───────────────────────────────────────▸       (most general)

1. Folder — variables on the request's own folder win first. If the name isn't there, Rest Hippo keeps walking up the folder hierarchy — each parent folder in turn, nearest ancestor first — so an inner folder overrides a value set on an outer one.
2. Collection environment — the active environment's variables, checked after the whole folder chain. Switching environments swaps these values.
3. Collection Global — the collection-wide set, checked last. Variables every request in the collection should see go here (each collection has its own Global set — see Environments below).

So a baseUrl set on the request's folder overrides one on a parent folder, which overrides the active environment's baseUrl, which in turn overrides the collection Global value — first match wins, nearest scope first.

Folder and collection-wide variables

Click a folder in the tree to edit its variables right in the center panel: the request editor is replaced by an inline variable editor scoped to that folder, and selecting a request switches the panel back. It offers the same bulk-text and key/value modes — and per-variable secure masking — as the other variable editors, and saves as you type.

Clicking a collection edits its Global environment in that same inline editor — collections no longer have a separate variable set; their collection-wide variables are simply the Global environment (also editable from the Collections manager's Environments tab).

Folder variable profiles

Folder variables give you targeted custom variables — scoped to just the requests under a folder — and a profile lets you flip those values without editing them. That makes profiles ideal for custom, exploratory testing: keep several value sets side by side and switch between them with a single keystroke.

A profile is a named alternate set of values for a folder's variables — handy when the same requests point at different back-ends (say Dev, Staging and Prod) that differ only in a host, key, or token. Profiles name value-sets for a folder's variables only — they never rename or re-value environment or Global variables (that's what environments are for).

Where a profile is visible

A profile belongs to the scope it was defined in, and is offered there and below it — nowhere else:

• This folder — visible on that folder and every folder inside it. A folder elsewhere in the collection never sees it, so its values can't be mistaken for ones that are available there.
• Whole collection — visible from every folder in the collection.

So if a folder defines two profiles and a subfolder inside it defines three, anything under that subfolder sees five, the parent folder sees its own two, and a folder alongside the parent sees none.

Because a profile only ever reaches its own subtree, two unrelated branches can each have their own Prod without either shadowing the other.

Every folder starts with a single Default profile — the plain variables you edit when no named profiles are in scope. The Default profile owns the variable set: it is the only profile where you can add, rename, remove, or mark a variable secure. Its controls live on the far right of the folder variable editor's toolbar:

• ＋ (Add profile) — always shown. It opens a small popup to name a new profile and choose its scope: This folder (the default) or Whole collection. Press Enter to create it, or Escape / click away to cancel. Creating a profile switches to it and copies the Default's variable names with their values cleared, ready for you to fill in. Each scope holds up to nine named profiles — the limit is per folder, so a full folder never stops its parent (or the collection) taking more. A scope at its limit is greyed out in the popup, and ＋ itself only when both are.
• Profile selector and 🗑 (Delete profile) — appear once at least one named profile is in scope. The selector lists Default plus every profile you can see here, grouped by where it was defined so you can tell at a glance which folder a profile belongs to.
• ✎ (Rename) and 🗑 (Delete) work on a profile defined on this folder, or on a collection-wide one. A profile inherited from a parent folder is shown greyed out with a tip naming the folder that owns it — go there to rename or delete it, so one folder can't pull a profile out from under its siblings.

How values behave:

• A profile overrides only what you set; everything else inherits the Default. Each variable in a named profile is either inherited (you haven't given it a value — it resolves to the Default's value) or an override (you've set your own). This is per variable, so a profile is an overlay of just the differences — the same everywhere a variable resolves: sending, the URL preview, generated cURL, and code snippets.
• In the editor, an inheriting field is blank with an "inherits default value" hint; typing a value makes it an override. A ↺ reset button (in place of the row's delete) drops an override so the variable inherits again — it's enabled only while the row is an override. Because inherit vs. override is tracked per variable, you can deliberately override to an empty value (clear an override's text but don't reset it): that sends a genuine blank rather than inheriting. (The bulk editor can't tell an empty override from an inherit, so there a blank line means inherit; use the table editor to force an empty value.)
• The variable set is fixed outside the Default. On a named profile the editor locks structure — you can edit values only; the name fields are read-only and the secure toggle is disabled. Add, rename, or remove a variable on the Default profile and every profile picks up the change (a new variable is inherited everywhere; a removed one drops out).
• A profile can only override names its folder already declares. It changes values; it never introduces a new variable.

Running several profiles at once

Because profiles are scoped, more than one can apply to the same request — one per scope. A collection-wide Staging and a folder's eu can both be active, and each folder resolves its variables with the outer profile applied first and the inner one on top. If both set the same variable name, the innermost one wins; a name only the outer profile touches still comes through. Selecting a profile only changes the selection for the scope that defines it — the others stay as they are.

A selection you make in one branch is remembered while you work in another. Step into a folder that can't see it and it simply doesn't apply; come back and it's still there.

Once a request has profiles in scope, a switch icon appears in the request editor — to the right of the URL preview's Copy button, or beside the Send button when the URL preview is hidden. Click it for a menu of every profile available to that request, grouped under the folder that defines it, with each group's own selection marked. All Default at the top clears every selection that applies here. A request in a folder with no profiles in scope gets no switch icon at all.

You can also switch from anywhere with the keyboard — hold ⌥⌘ (Cmd+Opt; Ctrl+Alt on Windows / Linux) and press a number: ⌥⌘0 sets everything in scope back to Default, and ⌥⌘1–⌥⌘9 pick the first through ninth profile available to the selected request, counting from the outermost scope inward (the order they appear in the selector). A number with no matching profile does nothing. Once more than nine profiles are in scope, only the first nine have a shortcut.

The selected profiles are live: requests resolve their folder variables using them, so switching profiles switches which back-end your requests hit. Profiles are independent of Environments — Environments switch the collection-wide (Global) values, profiles switch a folder's values; the two compose. A folder's own profiles and its per-profile values travel with it in a Rest Hippo export/backup, so exporting a folder carries the profiles it needs.

Environments

An environment is a named set of a collection's variables you can switch between. It's how you break a collection's variables down by deployment stage: define one environment each for Local, Dev, QA, and Production, and the collection's variables — baseUrl, credentials, IDs — flip to that stage's values in a single click. (Environments switch the collection-wide set; to switch a folder's values instead, use its profiles.)

Environments belong to the collection. Each collection has its own Global set and its own list of named environments, with its own active selection. When you switch the active collection, the environment picker and the active environment switch with it — so a Staging environment in one collection is entirely independent of a Staging in another. A brand-new collection starts with an empty Global set and no named environments.

Click the environment picker in the collections toolbar (it shows the active environment, e.g. LOCAL) to open a quick-switch menu. It lists Global followed by every named environment, with a check beside the active one — pick one to make it active instantly (all {{variables}} resolve against it).

To add, delete, or edit environments, open the Environments tab of the Collections manager — right-click the environment picker and choose Manage…, press ⌘/Ctrl + E, or open the collections manager and switch to the Environments tab. (A plain click on the picker only switches the active environment.)

• The Environment dropdown at the top selects which environment you're editing: Global (always present) or any named environment. Choosing one also makes it the active environment, kept in sync with the toolbar picker.
• + adds a named environment (type its name and press Enter); the trash button deletes the selected environment (with a confirmation). Global can't be deleted.
• Below the selector, the variable editor edits the selected environment's variables as a key/value grid (or as plain text via Bulk editor). Changes save automatically.

Secure variables

Mark a variable secure (the lock icon) to encrypt it at rest and mask it in the UI. Revealed secrets re-mask themselves automatically after a short time. Use secure variables for tokens and passwords you reference from auth fields.

Captures

Captures close the loop: after a request succeeds, pull a value out of the response and write it into a variable that later requests can use. A login request can capture the returned token; the next request sends it as a Bearer token — no copy-paste.

Configure them on the Captures tab of the request:

Each capture rule has:

For the Body source the same dot-path (.data.token, .items.[0].id) works whether the response is JSON, YAML, or XML — the body is parsed automatically and the path is walked over it. XML is addressed from its root element (e.g. <auth><token>…</token></auth> → .auth.token), and repeated tags become an indexable list (.list.item.[0]). A body that isn't one of those formats, or a path that finds nothing, is reported as a warning and captures nothing.

Choosing which response codes a rule fires on

Each rule has its own Codes selector — click it to open a checklist where you can tick whole status groups (1xx–5xx), choose Any status, or type specific codes (e.g. 201, 404) that appear as removable chips. A rule runs only when the response status matches its selector, so a single request can capture different values into different variables depending on the outcome — for example capture the access token from a 2xx body into token, but capture the error message from a 4xx body into lastError.

New rules default to 2xx, so captures keep firing only on success unless you opt a rule into other codes. When a value can't be found (missing field, empty body) the rule is reported as a warning and never overwrites a good value with an empty one.

Rest Hippo shows a small toast confirming what was written (e.g. Captured 1 variable → env.token), and the response status bar shows a captured badge.

Next: Functions →