Automating API Auth in Insomnia with Environment Variables and Response Tags

The problem: manual token handling slows you down

When you work against multiple API stages (dev, staging, prod) you often copy‑paste base URLs, refresh tokens, and adjust headers by hand. Each switch invites mistakes, and storing credentials in plain text inside requests makes sharing collections risky.

Thesis: combine Insomnia’s environment variables with Response Tags to get automatic, repeatable authentication and safe context switching

By defining stage‑specific variables (like base_url) and using the {{response}} tag to pull a token from a login request, you can build a self‑contained flow that:

• Switches environments with a single dropdown
• Obtains a fresh token without leaving the collection
• Injects that token into any downstream request

1. Set up hierarchical environments

Create three environments – Development, Staging, Production – each with the same variable names but different values.

# Development
base_url = https://api.dev.example.com
auth_path = /login
username = dev_user
password = dev_pass

# Staging
base_url = https://api.staging.example.com
auth_path = /login
username = stage_user
password = stage_pass

# Production
base_url = https://api.prod.example.com
auth_path = /login
username = prod_user
password = prod_pass

These variables can be referenced anywhere in a request: URL, headers, or body.

2. Build the authentication request

Create a request named Get Auth Token:

• Method: POST
• URL: {{base_url}}{{auth_path}}
• Body (JSON): { "username": "{{username}}", "password": "{{password}}" }

Assume the API returns JSON like:

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

To make that token available to other requests, add a Response Tag under the request’s "Test" tab:

{{response.token}}

Insomnia will store the extracted value in a temporary variable named token (you can see it in the environment panel after the request runs).

3. Use the token in downstream calls

Now any request that needs authentication can reference the token directly:

• Method: GET
• URL: {{base_url}}/users
• Headers: Authorization → Bearer {{token}}

When you run the collection, Insomnia will:

1. Execute Get Auth Token using the currently selected environment’s base_url, username, and password.
2. Extract the token from the response and store it.
3. Insert that token into the Authorization header of the Get Users request.

Worked example: switching from Dev to Staging

1. Select the Staging environment from the environment dropdown. 2. Click the Get Auth Token request and hit Send. – Insomnia builds the URL https://api.staging.example.com/login and sends the staging credentials. 3. Observe the response; the token appears in the response body and is automatically captured. 4. Send the Get Users request. – The URL becomes https://api.staging.example.com/users and the header reads Authorization: Bearer <staging‑token>. 5. Switch the dropdown to Production and repeat; the same flow now hits the prod endpoints with prod credentials.

Trade‑offs and limitations

Security: Environment variables are stored in plain text inside the Insomnia collection file. If you share the collection (e.g., via Git) without removing secrets, anyone with access can see usernames, passwords, and tokens. Mitigation: store only non‑sensitive identifiers in shared collections and keep real credentials in a local env.json file that is ignored by version control, or use Insomnia’s "Secure Vault" feature (if available).

Complexity: Chaining many Response Tags can create opaque dependencies. If the auth request fails, every subsequent request that relies on {{token}} will fail with a cryptic "undefined variable" error. Keep the chain short—ideally a single auth step—and document the dependency in the request’s description.

Actionable closing

Start by adding a single environment variable for your base URL, then create a minimal auth request that captures its token with a Response Tag. Test the flow in one environment, duplicate the environment for other stages, and verify that switching the dropdown updates all URLs and headers automatically. Keep the auth chain short, avoid committing plain‑text secrets, and you’ll have a reliable, repeatable way to move between dev, staging, and prod without manual token juggling.