Replace Hard-Coded URLs with Insomnia Collection Runs and Variables

The cost of duplicating requests per environment

When you test an API in dev, staging, and prod, the fastest approach—copying a request and editing the URL—quickly becomes the slowest. You end up with three nearly identical requests, three places to update a header, and three chances to forget a token rotation. The useful takeaway is that you can define the request once and let the environment supply the differences.

How Insomnia variables work

Insomnia resolves text wrapped in double curly braces—{{variable}}—at send time. You define these variables in the Settings → Variables panel. Variables can be scoped globally or attached to a specific environment, which means a single request can reference {{baseUrl}} and {{apiToken}} without knowing which server it will hit.

Because resolution happens when the request is sent, the same collection can target different hosts without editing the request itself. The active environment determines which value wins. Menu labels and layout can vary between Insomnia versions; if you do not see Settings → Variables, look for an environment or variables pane in the application sidebar.

Building a portable collection

Start with one request, such as GET {{baseUrl}}/users. Add an Authorization header with the value Bearer {{apiToken}}. Place that request inside a collection. When you create additional requests for the same API, reuse the same {{baseUrl}} pattern rather than pasting a full hostname.

If your team shares the collection through a Git sync or export, keep production credentials out of the shared file. Store them only in local or environment-specific variable files that are not committed.

Running the collection across environments

Insomnia's collection runner executes every request in a folder or collection sequentially. Before you run it, select the target environment from the environment dropdown. The run history records which environment was active, so you can distinguish a dev run from a prod run after the fact.

This is faster than manually sending individual requests, and it surfaces ordering or dependency issues early.

Worked example: switching from dev to prod

Assume you have two environments defined in the Variables panel:

• dev: baseUrl = https://dev.api.example.com, apiToken = <dev-token>
• prod: baseUrl = https://prod.api.example.com, apiToken = <prod-token>

Select dev, then run the collection. The request should resolve to https://dev.api.example.com/users with the dev token. Switch the environment selector to prod and run the same collection again. No request fields change; only the variable values do. Check the run log to confirm the active environment matches your intent before trusting the results.

Trade-offs and limitations

Variable substitution introduces indirection. A typo in a variable name—remember that names are case-sensitive—will cause the request to fail or send an unresolved {{placeholder}} rather than returning an obvious configuration error. Large collections can also make the Insomnia UI sluggish, so split very large suites into focused collections.

Because the runner sends real HTTP requests, running a prod environment collection is a state-changing operation if the API has side effects. Treat prod runs with the same caution you would apply to any live traffic.

Practical verification

To confirm the setup works:

1. Open Settings → Variables and add baseUrl and apiToken for at least two environments.
2. Create a request with URL {{baseUrl}}/users and an Authorization header using {{apiToken}}.
3. Select one environment and run the request. Verify the resolved host in the request preview or response metadata.
4. Switch environments, rerun, and confirm the run log reflects the new environment.

If the resolved URL still points to the old host, check for a global variable overriding the environment-scoped value, and confirm the environment selector actually changed before the run started.