Why Chain Requests?
Many real-world API workflows are multi-step: log in to get a token, then use that token to create an order, then fetch the order to confirm it. Chaining requests in Postman means the output of one request — a value pulled out of its response — becomes the input of a later one, letting a single Collection Runner or Newman pass exercise an entire realistic user journey rather than isolated, disconnected calls.
Cricket analogy: Like a fielding captain's bowling change decision after over ten setting up who bowls the death overs — one phase's outcome directly shapes the next phase's plan.
Extracting Values in a Test Script
Extraction happens in the first request's Tests tab: you parse the response with pm.response.json(), pull out the fields you need, and store them with pm.collectionVariables.set() or pm.environment.set() so later requests can reference them with {{variableName}}. This is the same pm API used for assertions — extraction and validation typically live side by side in the same test script.
Cricket analogy: A scorer notes the not-out batsman's score at the end of an over so it correctly carries forward as the starting score for the next over.
pm.test("Login succeeded", function () {
pm.response.to.have.status(200);
});
const responseJson = pm.response.json();
pm.collectionVariables.set("authToken", responseJson.token);
pm.collectionVariables.set("userId", responseJson.user.id);
// Next request's Authorization header: Bearer {{authToken}}
// Next request's body can reference {{userId}}The Collection Runner and Newman both execute the requests in a collection sequentially, top to bottom, within a single run — which is exactly what makes chaining reliable: a variable set by request 1's test script is guaranteed to exist before request 2 sends.
Referencing Extracted Data in Later Requests
Once a value is stored, a later request references it with {{authToken}} in an Authorization header or {{orderId}} inside a URL path, and Postman resolves it at send time. Which scope you chose when storing it matters: collection variables persist across the whole collection and across runs until overwritten, while environment variables depend on whichever environment is currently active in the top-right selector.
Cricket analogy: Like a captain referring to the required run rate calculated after the previous over to decide the field and bowling change for the next over.
Collection and environment variables set at runtime persist after the run finishes. If you re-run a chained flow without resetting authToken or orderId, a stale value from the previous run can accidentally satisfy an assertion, hiding a real regression — clear or reset these variables at the start of a run when isolation matters.
- Chaining requests means one request's response data becomes input for a later request in the same flow or Runner iteration.
- Extract values in the first request's Tests tab using pm.response.json() and store them via pm.collectionVariables.set() or pm.environment.set().
- Reference stored values in later requests with {{variableName}} syntax in URLs, headers, or bodies.
- Collection Runner and Newman execute requests sequentially, so variables set earlier in the run are available to requests later in the same run.
- Variable scope determines lifetime: collection variables persist across runs until cleared, while local pm.variables only last for the current script execution.
- Stale values from a previous run can mask real bugs — reset or scope variables carefully when test isolation matters.
Practice what you learned
1. What's the typical way to pass an auth token from a login request to subsequent requests?
2. Which method parses a response body as JSON inside a test script?
3. In a Collection Runner run of 3 requests executed in order, when does a variable set in request 1's test script become available to request 3?
4. What risk comes with reusing collection variables across multiple test runs without resetting them?
5. Which syntax do you use inside a request URL or body to reference a stored variable named orderId?
Was this page helpful?
You May Also Like
Pre-request Scripts
How to run JavaScript before a Postman request is sent, to set variables, compute signatures, and build dynamic request data.
Test Scripts Basics with pm.test()
How to write assertions in Postman's Tests tab using pm.test() and pm.expect() to automatically validate API responses.
The pm API: Request, Response, and Environment
A tour of Postman's core pm object — pm.request, pm.response, and pm.environment — the JavaScript API used in both pre-request and test scripts.
Dynamic Variables and Faker Data
How to use Postman's built-in dynamic variables like {{$guid}} and {{$randomEmail}} to generate realistic fake data on every request.