Stop Copy-Pasting Tokens: Hoppscotch Environments and Pre-Request Scripts in Practice

You are testing a REST API. The base URL changes between staging and production. The Bearer token rotates every hour. You copy the token into the Authorization header of the first request, then the second, then the tenth. When the token expires, you repeat the process. This manual copying is not just tedious—it is a source of stale values, missed headers, and requests that fail for reasons unrelated to the API itself.

Hoppscotch addresses this with two features that work together: environment variables for static substitution and pre-request scripts for dynamic behavior. The combination lets you define a value once and inject it into many requests automatically. The trade-off is that the scripting runtime is deliberately sandboxed, and the default storage is not designed for production secrets.

The copy-paste tax

When a URL or header is duplicated across requests, every change becomes a find-and-replace exercise. If you miss one occurrence, you get a 401 or a 404 that looks like an API bug. The maintenance cost scales with the size of your collection.

Environments as a single source of truth

An environment in Hoppscotch is a named set of key-value pairs. You reference them in request fields with double curly braces. For example, create an environment named dev with two variables:

baseUrl = https://api.example.com
token = abc123

Set the request URL to {{baseUrl}}/users. When you send the request, Hoppscotch substitutes the variable before the HTTP call. If the base URL changes, you edit one field in the environment, not every request.

Pre-request scripts for dynamic headers

Variables handle substitution, but sometimes you need logic. Hoppscotch runs a pre-request script in JavaScript before the request is sent. This is useful for headers that depend on other variables or for computed values.

Using the dev environment above, attach this pre-request script to the request:

pm.request.headers.set('Authorization', `Bearer {{token}}`);

Alternatively, read the variable explicitly with pm.environment.get('token') and build the string in code. Either way, the script runs in Hoppscotch’s sandbox and modifies the outgoing request headers. The pm object is the scripting API surface; it exposes request, environment, and collection helpers.

Worked example: migrating one repetitive request

Suppose you have a request that currently hard-codes the full URL and a manually pasted token. Migrate it in three steps.

1. Create an environment named dev (or reuse an existing one). Add baseUrl and token variables.
2. Change the request URL to {{baseUrl}}/users.
3. Add the pre-request script shown above to set the Authorization header.

Send the request. If the API responds as it did before the migration, the substitution and script worked. If you see a 401, check that the token value in the active environment matches the expected credential.

Verifying the behavior locally

You can confirm that variable substitution and script execution work without calling a real API. Create a new environment and add a variable testVar with the value hello. Create a request with the URL https://httpbin.org/anything and this pre-request script:

console.log(pm.environment.get('testVar'));

Open your browser’s developer console (F12 or Ctrl+Shift+J / Cmd+Option+J) before sending the request. The expected check is that the console displays hello. This confirms the script executed and the variable was readable.

To verify the sandbox restriction, add require('fs') to a pre-request script. The script is expected to throw an error because the sandbox does not expose Node’s module system. This is a useful diagnostic: if you are porting a script from Postman or another tool and it references fetch, require, or the file system, it will fail in Hoppscotch.

Trade-offs: sandbox limits and secrets

The scripting engine is powerful but intentionally constrained. It supports a subset of JavaScript; globals such as fetch and require are unavailable. Complex asynchronous logic or local file access is out of scope. Treat pre-request scripts as lightweight request mutators, not as a general-purpose runtime.

The larger limitation is secrets management. Environment variables are stored in plain text in the browser’s local storage unless you enable an optional encrypted vault feature. That vault may not be available in every self-hosted deployment. A token pasted into an environment is readable by anything with access to that browser profile.

Data type	Recommended location	Reason
Base URLs, feature flags	Hoppscotch environment	Low sensitivity, high reuse
Short-lived test tokens	Hoppscotch environment (local only)	Convenient for throwaway testing
Production API keys, long-lived secrets	External vault or CI secret store	Avoid plain-text browser storage

Where to start

Do not migrate your entire collection at once. Pick one request that currently contains a hard-coded base URL and token. Create a single environment, replace the literals with variables, and add a short pre-request script for the auth header. Run the verification check with testVar to confirm your setup. Once that pattern feels natural, extend it to the rest of the collection and share the environment definition with your team—while keeping real credentials outside Hoppscotch.