Stop Copy-Pasting Tokens: Chaining API Requests with Postman Variables

The Manual Token Shuffle

Most API developers have experienced the "copy-paste loop": you send a login request, copy the access_token from the JSON response, navigate to another request, and paste that token into the Authorization header. When the token expires, you repeat the process. This is not only slow but introduces errors when testing across different environments like staging and production.

The solution is request chaining. By using Postman's environment variables and post-response scripts, you can automate the extraction of values from one response and inject them into subsequent requests, turning a manual sequence into a seamless workflow.

Understanding Variable Scope Precedence

Postman uses a hierarchical system for variables. When you reference a variable using the {{variable_name}} syntax, Postman searches for the value in a specific order of precedence (from narrowest to broadest):

• Local: Temporary variables used within a single request or script.
• Data: Variables defined in a CSV or JSON file during a Collection Runner execution.
• Environment: Variables specific to a deployment target (e.g., dev, prod).
• Collection: Variables shared across all requests within a specific collection.
• Global: Variables accessible across the entire workspace.

Using pm.environment.set() is generally the best practice for chaining because it keeps your credentials isolated to a specific environment without polluting your global workspace. Note that the older postman.setEnvironmentVariable API is deprecated; use the pm.* API in current Postman versions.

Implementing the Chain with Post-Response Scripts

Postman allows you to write JavaScript in the "Tests" (post-response) tab of a request. These scripts execute immediately after the response is received. You can use the pm API to parse the response body and update your environment variables automatically.

Worked Example: Authentication to Resource Retrieval

Consider a scenario where you must log in to get a token, create a resource to get an ID, and then fetch that specific resource.

Step 1: The Login Request

In the Tests tab of your POST /login request, add the following script:

// Parse the JSON response
const responseData = pm.response.json();

// Extract the token and save it to the environment
if (responseData.token) {
    pm.environment.set("authToken", responseData.token);
    console.log("Auth token updated successfully.");
} else {
    console.error("Token not found in response");
}

Step 2: The Create Resource Request

Set the Authorization header of this request to Bearer {{authToken}}. In the Tests tab of the POST /items request, capture the new ID:

const responseData = pm.response.json();

if (responseData.id) {
    pm.environment.set("itemId", responseData.id);
}

Step 3: The Get Resource Request

Configure the URL as GET /items/{{itemId}} and the Authorization header as Bearer {{authToken}}. When you run these in sequence, Postman resolves the placeholders automatically.

Moving from UI to CI/CD

Once your chain is established, you no longer need to click through the UI. You can use the Collection Runner to execute the entire sequence. Because the variables are handled programmatically, this collection can be exported and run headlessly using Newman, Postman's CLI companion.

To run your chained flow via Newman, use the following command in your terminal (requires Node.js and Newman installed):

# Run the collection using a specific environment file
newman run my_collection.json -e my_environment.json

Risk Note: Ensure you have permission to execute shell commands in your environment, and never commit exported environment files to public version control, as they may contain live tokens. Check the current Newman documentation for exact CLI flags, as these evolve between versions.

Trade-offs and Limitations

While chaining reduces manual work, it introduces hidden state. A developer opening your collection for the first time won't see where {{itemId}} comes from just by looking at the request; they have to hunt through the scripts of previous requests.

To mitigate this, always document the required environment variables in the collection's description field. Additionally, be cautious with pm.environment.set() in shared team workspaces; if multiple people run the same collection against the same environment simultaneously, they may overwrite each other's tokens. For real secrets, prefer Postman's secret-type variables or an external vault rather than plain environment values, since exported environments can leak credentials.

Verification Checklist

• Verify that the {{variable}} in the request header is highlighted as resolved after the first request runs (hover over it to see the current value).
• Check the Postman Console to confirm your console.log statements show the token was captured.
• Run the full sequence in the Collection Runner and confirm it completes without 401 Unauthorized errors.
• Run the exported collection with Newman locally to confirm the chained flow works outside the Postman UI.