Managing API Variables in Hoppscotch: Scopes, Scripts, and Sharing

Problem: Keeping API Tests Consistent Across Environments

When testing an API you often need the same base URL, authentication token, or timestamp across many requests, but you also want to override certain values for a specific environment (e.g., staging vs. production) or a single endpoint without duplicating entire collections. Manually copying values leads to drift and makes updates error‑prone.

Thesis: Hoppscotch’s variable scoping and pre‑request scripts let you define values once, reuse them everywhere, and override them only where needed.

1. Variable Scopes and Lookup Order

Hoppscotch supports three layers of variables:

• Global – available to every workspace and request.
• Workspace – shared among all requests in the current workspace.
• Request‑level – defined directly on a request and takes highest precedence.

The lookup order is request → workspace → global. If a variable with the same name exists at multiple levels, the request‑level value wins, allowing you to override a workspace or global setting for a single call without changing the shared definitions.

2. Defining and Reusing Variables

Variables are referenced with the Mustache syntax {{variableName}}. To create a variable:

1. Open the Variables panel (gear icon) in the workspace sidebar.
2. Click Add Variable, enter a name (e.g., baseUrl) and a value (e.g., https://api.example.com).
3. Choose the scope: Global, Workspace, or Request (the latter appears only when editing a specific request).

Once defined, you can use {{baseUrl}} in any URL field, header, or body. Changing the value in one place updates every request that references it.

3. Adding Dynamic Values with Pre‑Request Scripts

For values that must be computed at runtime (e.g., a bearer token, a timestamp, or a random nonce), Hoppscotch lets you run JavaScript before a request is sent.

Example: generate a UTC timestamp and store it as a workspace variable.

// Pre‑request script for a request
const now = new Date().toISOString();
pm.environment.set('timestamp', now);

Then reference {{timestamp}} in headers or query parameters. Because the script runs with each request, the value stays current.

You can also compute authentication tokens:

// Example: simple HMAC‑SHA256 (requires a crypto library)
const secret = pm.environment.get('apiSecret');
const timestamp = pm.environment.get('timestamp');
const hash = CryptoJS.HmacSHA256(timestamp, secret).toString(CryptoJS.enc.Hex);
pm.environment.set('signature', hash);

Note: Hoppscotch does not bundle CryptoJS by default; you would need to include it via a CDN in the script or pre‑compute the token elsewhere.

4. Sharing Variable Sets via Import/Export

To keep variable definitions in version control, export the workspace:

1. Click the workspace name → Export Workspace.
2. Save the generated JSON file.
3. Commit the file to your Git repository.

The exported JSON contains a variables array with each variable’s name, value, and scope. To import into a fresh Hoppscotch instance:

1. Open Hoppscotch.
2. Select Import Workspace and choose the JSON file.
3. All variables, scripts, and requests are restored, preserving the original scopes.

Trade‑off: Readability vs. Offline Caching

While pre‑request scripts are powerful, placing complex logic inside them can make a request harder to read at a glance. Moreover, Hoppscotch caches request collections for offline use; scripts that rely on external libraries or dynamic network calls may break when the app is offline. A practical approach is to keep scripts limited to simple computations (timestamps, basic token generation) and move heavier logic to external scripts or environment‑specific variable sets.

Limitations and How to Verify

Variable names are case‑sensitive and must not clash with Hoppscotch’s built‑in globals like $uuid or $timestamp. Overriding a built‑in unintentionally will cause unexpected values to appear in requests.

To verify that a variable is set correctly:

1. Add the variable reference (e.g., {{token}}) to the Authorization header as Bearer {{token}}.
2. Open the request’s Inspect panel after sending.
3. Confirm the header shows the expected value (e.g., Bearer test123).

If the header still shows the raw {{token}}, the variable is either undefined at that scope or blocked by a naming conflict.

Actionable Closing

Start by identifying values that are repeated across your API collection—base URLs, common headers, or timestamps. Define them at the global or workspace level, use {{variableName}} syntax to reference them, and add a pre‑request script only when you need runtime computation. Export the workspace to keep these definitions under Git control, and always verify the final request headers to catch scoping issues early. This strategy reduces duplication, makes environment switches trivial, and keeps your API tests maintainable.