Configuring Hoppscotch Environment Variables for Dynamic API Requests

The problem: hardcoded values in every request

If you test an API across local, staging, and production servers, you end up editing the base URL, tokens, and IDs in every saved request each time you switch targets. Hoppscotch environments solve this: you define key-value pairs once, reference them with {{variable}} syntax anywhere in a request, and swap the entire context by selecting a different environment from a dropdown.

This guide covers creating an environment, referencing variables, updating them at runtime with scripts, and verifying that values resolve correctly. It applies to the Hoppscotch web app and desktop app; the UI layout is broadly the same in both, though exact menu positions can shift between releases.

Prerequisites

• Hoppscotch running at hoppscotch.io or a self-hosted instance, or the desktop app.
• At least one saved request (or a draft request) you want to parameterize.
• If you plan to share environments with a team, a Hoppscotch account and a shared workspace. Personal workspaces work fine for solo use.

Create an environment and define variables

1. Open the Environments panel (the layered-square icon in the left sidebar in current versions).
2. Click Add new environment and give it a name that describes the target, for example staging or local-dev.
3. Add variables as key-value rows. A typical starter set:

   baseUrl    = https://staging.api.example.com
   authToken  = eyJhbGciOi...
   userId     = 42

4. Save the environment, then select it as the active environment using the environment selector (usually a dropdown at the top of the Environments panel or near the request bar).

Two naming rules trip people up. Variable names are case-sensitive: {{baseUrl}} and {{baseurl}} are different variables. And names must not contain spaces or special characters — stick to letters, digits, and underscores. An unsupported name will fail to resolve and the literal {{...}} text gets sent in the request.

Reference variables in requests

Anywhere Hoppscotch accepts text in a request — URL, headers, query parameters, body — you can insert {{variableName}}. For example:

GET {{baseUrl}}/users/{{userId}}
Authorization: Bearer {{authToken}}

Hoppscotch highlights recognized variables in the editor; an unrecognized name typically renders without the resolved-value styling, which is your first visual cue that something is misspelled or the wrong environment is active.

Update variables at runtime with scripts

Static values cover URLs and fixed IDs, but tokens expire and chained requests need values from earlier responses. Hoppscotch supports two script hooks, written in JavaScript:

Pre-request scripts

Run before the request is sent. Use them to compute values such as timestamps:

pw.env.set("requestTime", Date.now().toString());

Then reference {{requestTime}} in a header. Note the API object is pw in Hoppscotch, not pm as in Postman — scripts copied from Postman collections need adjusting.

Test scripts

Run after the response arrives. Besides assertions, they can capture response data into the environment for the next request in a chain:

pw.test("status is 200", () => {
  pw.expect(pw.response.status).toBe(200);
});

const body = pw.response.body;
pw.env.set("authToken", body.access_token);

Run your login request once, and every subsequent request using {{authToken}} picks up the fresh token.

Share environments via export and import

In the Environments panel, use the environment's options menu to Export as JSON. A teammate imports the file through the same panel. Two cautions:

• Exported files contain the values in plain text. If authToken holds a real credential, treat the JSON file like a secret — do not commit it to a public repository. Consider exporting with placeholder values and letting each developer fill in their own secrets.
• Hoppscotch also distinguishes secret variables in some versions, masking their values in the UI; check whether your version masks them in exports before sharing.

Verify the setup

Do not assume resolution worked — check it:

1. Request log check. Send a request that uses {{baseUrl}}, then open the response/request details. Confirm the actual URL sent shows the resolved value, not the literal placeholder. A literal {{baseUrl}} in the sent request means the variable is undefined in the active environment.
2. Console check for scripts. Add console.log(pw.env.get("authToken")) to a pre-request script, run it, and open Hoppscotch's console output to confirm the script executed and the value is what you expect.
3. Import round-trip. After importing an environment JSON, select it and visually confirm every key-value pair appears in the panel before running requests against it.

Common failure modes and recovery

None of these steps change server-side state, so recovery is simply editing the environment or script and re-sending. The one real risk is operational: sending a request with a stale-but-valid token against the wrong environment (for example, a destructive call aimed at production while you thought staging was active). Make a habit of glancing at the active-environment indicator before any mutating request.