Environments & Variables

Variables let you reuse values — base URLs, tokens, account IDs, anything — across many requests without retyping them. Define a value once, reference it with {{name}}, and HTTPBot fills it in every time you send the request.

This is the backbone of working efficiently in HTTPBot: point the same set of requests at staging or production by flipping a single switch, keep secrets out of your request bodies, and share Collections without baking in environment-specific details.

How variables work

HTTPBot uses Mustache-style templates. Anywhere a value is accepted, wrap a variable name in double curly braces:

{{variable}}

When you send a request, HTTPBot replaces each {{variable}} with its current value. You can reference variables in just about every field of a request:

A typical URL might look like this:

https://{{baseUrl}}/users/{{userId}}

With baseUrl set to api.staging.example.com and userId set to 42, HTTPBot sends the request to https://api.staging.example.com/users/42. Change the value of baseUrl in one place and every request that uses it follows along.

A request URL containing a baseUrl variable alongside the active environment indicator.A request URL containing a baseUrl variable alongside the active environment indicator.A request URL containing a baseUrl variable alongside the active environment indicator.

You can combine static text and variables freely, and you can use more than one variable in a single field. Path variables (the :id style segments) are also resolved against your variables before the request is sent.

Scopes & precedence

HTTPBot resolves a {{variable}} by looking through three scopes. If the same name exists in more than one scope, the more specific scope wins.

Scope Where it lives Applies to
Global Variables Settings → Global Variables Every request, app-wide
Collection variables Defined on a Collection Requests inside that Collection
Environment The currently active Environment Every request, while that Environment is active

When a request is sent, the scopes are merged in this order, with each later scope overriding earlier ones:

  1. Global Variables are applied first.
  2. Collection variables for the request's Collection are applied next, overriding any Global Variable of the same name.
  3. The active Environment's variables are applied last, overriding both.

In other words: an active Environment beats a Collection variable, and a Collection variable beats a Global Variable. This lets you set a sensible default globally (or on a Collection) and then override it for a specific environment such as Staging or Production.

The Global Variables editor showing a few key/value pairs.The Global Variables editor showing a few key/value pairs.The Global Variables editor showing a few key/value pairs.

Global Variables

Global Variables are always in effect, regardless of which Environment is active or which Collection a request belongs to. They're a good home for values that rarely change — a default API host, a shared API version header, or a feature flag you toggle occasionally.

Open them from Settings → Global Variables, or from a request's … menu → Environment → Global Variables. Each entry is a key/value pair.

Collection variables

A Collection can carry its own variables, scoped to the requests inside it. These are handy when a set of requests shares a value that doesn't belong to your whole app — for example, a resource ID used only by one API's endpoints. See Collections & Folders for where to edit them.

Environments

An Environment is a named set of variables you can activate and deactivate. Only one Environment is active at a time, and its values override Global and Collection variables while it's active. Switching Environments is the fastest way to repoint the same requests at a different server or account.

Each Environment is simply a list of key/value pairs — for example a Staging Environment and a Production Environment that each define baseUrl, apiKey, and userId with different values.

HTTPBot keeps two kinds of Environments:

The Environments list with the Local / Postman picker.The Environments list with the Local / Postman picker.The Environments list with the Local / Postman picker.

Creating and editing an Environment

  1. Open the Environments list — from a request's … menu → Environment → Manage Environments, or from Settings → Environments.
  2. Tap the + button and choose New Environment.
  3. Give it a name (for example, Staging).
  4. Add key/value pairs — one row per variable.
  5. Save.

To edit an Environment later, reopen the list and select it. You can also import Environments from a file or from Postman using the + menu in the Environments list.

Switching the active Environment

You can activate an Environment in two places:

When an Environment is active, every request resolves its {{variables}} against that Environment first. To stop using any Environment, choose Deactivate from the request … menu → Environment. With no Environment active, requests fall back to Collection and Global Variables only.

The request menu Environment submenu showing Deactivate, Global Variables, Manage Environments, and the list of Environments.The request menu Environment submenu showing Deactivate, Global Variables, Manage Environments, and the list of Environments.The request menu Environment submenu showing Deactivate, Global Variables, Manage Environments, and the list of Environments.

Tips

Related