Chaining Authenticated Calls in Insomnia: Use {% response %} to Auto‑Inject Tokens

Problem Statement

When testing a multi‑step API that requires authentication, you often need to run a login request first, grab the token it returns, and then use that token in subsequent requests. Doing this manually—copying the token, pasting it into a header, and re‑running the calls—is error‑prone and slows down experimentation. Insomnia’s {% response %} template tag lets you automate this chain so that a single click on the authenticated request will trigger the login request, extract the token, and inject it into the Authorization header.

Prerequisites

• Insomnia Desktop 10.x or newer (the {% response %} tag is supported from 10.0 onwards).
• An HTTP collection that contains at least two requests:
  • Login request – e.g., POST /auth/login that returns a JSON body containing the token.
  • Authenticated request – e.g., GET /me that requires a Bearer token.
• Environment variables for the base URL and user credentials (e.g., {{BASE_URL}}, {{USERNAME}}, {{PASSWORD}}). These should be stored in a base environment with per‑stage sub‑environments (dev, staging, prod) to keep the chain portable.
• Knowledge of the JSONPath that points to the token in the login response (e.g., $.data.accessToken).
• At least one successful run of the login request so that Insomnia knows the request’s exact shape and ID.

Step 1: Identify the Login Request ID

In Insomnia, each request has a unique ID shown in the UI. Right‑click the login request and select Copy Request ID (or view the ID in the request’s details panel). The ID looks like req_123abc456def and is what the {% response %} tag uses to locate the request. Using the ID instead of the display name protects the chain from breaking if you rename the request later.

Step 2: Configure the Login Request

POST {{BASE_URL}}/auth/login
Content-Type: application/json

{
  "username": "{{USERNAME}}",
  "password": "{{PASSWORD}}"
}

Run this request once. Verify that the response body contains the token field you intend to extract. Note the exact JSONPath; for example, if the body is:

{
  "data": {
    "accessToken": "eyJhbGciOiJ..."
  }
}

then the JSONPath is $.data.accessToken.

Step 3: Configure the Authenticated Request

Open the request that needs the token (e.g., GET /me) and set its Authorization header to use the {% response %} tag. Replace REQ_ID with the ID you copied earlier and JSON_PATH with the path you identified.

GET {{BASE_URL}}/me
Authorization: Bearer {% response 'body' '$.data.accessToken' 'REQ_ID' %}

When you send this request, Insomnia will first execute the login request, extract the token from its JSON body, and then substitute the value into the Authorization header. The header will appear resolved in the request preview after the call finishes.

Step 4: Verify the Chain

1. Timeline check: Open the Timeline tab for the authenticated request. You should see two entries: the login request (executed first) and the actual /me call.
2. Header preview: In the Request tab, the Authorization header should display the resolved token string, not the {% response %} tag.
3. Response status: The HTTP status should match the expected success code (e.g., 200). If you receive a 401, the token extraction likely failed.
4. Console output: Open the Console panel. There should be no “Template evaluation error” messages. If you see errors, they will point to a malformed JSONPath or a missing request ID.

Step 5: Troubleshooting & Recovery

• Tag renders literally: The header still shows the {% response %} tag. Verify that:
  • The request ID matches exactly (including case).
  • The JSONPath is correct and uses the proper syntax (e.g., $.data.accessToken).
  • The login request’s response actually contains the token field.
• Login request fails: The chain will stop because the token cannot be extracted. Inspect the login request’s response for errors (missing credentials, wrong endpoint, etc.). Fix those before retrying the authenticated request.
• Stale token: If the token is short‑lived, you might see a 401. Confirm that the login endpoint issues a fresh token each time and that you’re not reusing an old one from a stored environment variable.
• Rate‑limit or side effects: Because {% response %} re‑executes the login request on every evaluation, you may hit rate limits or trigger side effects (e.g., creating a new session). If this occurs, consider storing the token in a temporary environment variable after the first run, or use a vault integration.

Step 6: Reuse in CI or Headless Runs

To run the same chain outside the GUI (e.g., in a CI pipeline), export the collection to YAML:

insomnia export --format yaml --output api_collection.yaml

Then use the Inso CLI to execute the authenticated request:

inso run api_collection.yaml --env-dev --request GET_me

Replace GET_me with the request’s name or ID. The CLI will honor the {% response %} tag and perform the same chaining logic.

Limitations & Best Practices

• Re‑execution cost: Each evaluation of the {% response %} tag triggers a fresh login call. For high‑frequency tests or rate‑limited endpoints, this can be problematic.
• Version sensitivity: JSONPath support and the exact syntax of the {% response %} tag are tied to the Insomnia version. Verify the behavior in your installed build if you upgrade.
• Security: Tokens extracted via the tag are transient and not stored in the environment file. However, if you later copy the token into an environment variable, it will persist on disk. Prefer vault integrations or the tag for sensitive data.
• Endpoint changes: If the login endpoint’s response shape changes (e.g., the token field is renamed), the chain will break at runtime. Keep the JSONPath up‑to‑date and run a quick check after any API change.
• No rollback: The {% response %} tag only injects data; it does not modify the request after it has been sent. Therefore, there is no state change to revert.

Conclusion

By leveraging the {% response %} template tag and request IDs, you can turn a multi‑step authentication flow into a single, repeatable Insomnia request. This eliminates manual copy‑paste, reduces errors, and keeps your environment clean. Follow the steps above to set up the chain, verify it, and integrate it into automated pipelines.