G4 · Pre-request Script and Test: Test chaining CARRIES the `id` PRODUCED by a POST request into the next GET request — the Postman counterpart of passing a method's return value
Test chaining CARRIES the `id` PRODUCED by a POST request into the next GET request — the Postman counterpart of passing a method's return value as a PARAMETER to the next method in Java. Writing `pm.environment.set('bugId', body.id)` in the `Tests` tab WRITES the id from the POST response into the `{{bugId}}` variable you defined in G2; the next request READS and uses that value. So why is this better than testing everything in one request? Because a real user flow is EXACTLY like this: a bug is FIRST created, THEN acted upon BY REFERENCE — test chaining EXACTLY simulates this real flow. **For a deep pre-request script guide → see the `/postman` page.**
pm.environment.set("bugId", 42)
The real flow was tested
`POST /api/v1/bugs` runs — the server creates a NEW record, returns `id: 42`.
The script in the Tests tab CAPTURES this id and saves it with `pm.environment.set(...)`.
The `{{bugId}}` variable now carries the REAL id value (42) — READY for the next request.
When `GET /api/v1/bugs/{{bugId}}` runs, Postman AUTOMATICALLY turns it into `/api/v1/bugs/42`.
The lesson — the two requests are now LINKED; this is an EXACT test of the real user flow "create first, then act by reference".
The Order for Chaining Two Requests
Create a new bug, observe the id in the response.
Write pm.environment.set('bugId', body.id) in the Tests tab.
In the next request, query the same record using the {{bugId}} variable.
Order the steps for building a test chain in Postman.