Postman Collections & Environments

API Testing & Tooling — Postman Collections & Environments

API Testing & Tooling

Chapter 3 · Postman Collections & Environments

🗂️ Postman Collections & Environments

Chapter 2 ended by saving one request. That works for one request — it stops working the moment there are thirty of them, scattered across dev, staging, and production servers. This chapter fixes both problems: collections organize related requests, and environments let the same collection point at a different server without editing a single request.

Collections: Organizing Related Requests

A collection is a named group of saved requests — and folders inside a collection group them further. A "Shop API" collection might have a Products folder, an Orders folder, and a Users folder, each holding the requests relevant to that part of the API, instead of one long unsorted list that gets harder to navigate with every request saved.

Shop API (collection)
├── Products
│   ├── List Products
│   ├── Get Product by ID
│   └── Create Product
├── Orders
│   ├── Create Order
│   └── Get Order Status
└── Users
    ├── Login
    └── Get Current User

Environment Variables

Hardcoding https://api.example.com into thirty saved requests means editing thirty requests the day that URL needs to change — or worse, needing a completely different URL for local development versus production. An environment defines variables like baseUrl, and every request in the collection references {{baseUrl}} instead of a literal URL.

// The request itself, written once:
GET {{baseUrl}}/products/42

// Dev environment:      baseUrl = http://localhost:3000
// Staging environment:  baseUrl = https://staging.example.com
// Production environment: baseUrl = https://api.example.com

Switching the active environment in Postman's environment dropdown changes where every request in the collection points, without touching any of them individually.

Collection Variables vs. Environment Variables

Two Kinds of Variable, Two Different Jobs

Collection Variables

Shared across every environment — good for values that don't change between dev/staging/prod, like an API version path segment (/v2) used the same way everywhere.

Environment Variables

Specific to whichever environment is currently active — good for values that genuinely differ per environment, like the base URL itself or an environment-specific API key.

Scope	Typical Use
Global	Rarely used deliberately — visible everywhere, in every collection; easy to lose track of what set it
Collection	Shared across all environments for this one collection (e.g. a fixed API version path)
Environment	Differs by active environment (base URL, environment-specific credentials)
Local (a single request's own overrides)	Temporary, request-specific tweaks that shouldn't affect anything else

Chaining Requests: Using One Response in the Next

A common real pattern: logging in returns an auth token, and every subsequent request needs that token in its Authorization header. Without chaining, that means manually copying the token out of one response and pasting it into the next request, every single time. Postman's response pane has a quicker path: selecting a value in the response and choosing "Set as variable" saves it directly into the active environment — no copy-paste required, and no code, which is deliberately left for Chapter 4's scripting.

Chaining a Login Into an Authenticated Request

// Request 1: Login
POST {{baseUrl}}/login
Body: { "email": "dana@example.com", "password": "..." }

// Response: { "token": "eyJhbGciOi..." }
// -> Select the token value -> "Set as variable" -> saved as {{authToken}}

// Request 2: Get Current User, reusing that token
GET {{baseUrl}}/me
Authorization: Bearer {{authToken}}

Request 2 never hardcodes a token — it reads whatever {{authToken}} currently holds, which Request 1 just set. Re-running Request 1 automatically refreshes it for every request that follows.

💻 Coding Challenges

Challenge 1: Organize a Collection

A "Blog API" needs requests for: listing posts, getting one post, creating a post, listing comments on a post, and creating a comment. Propose a folder structure for this collection.

Goal: Practice grouping related requests logically, the same way this chapter's Shop API example was organized by resource.

→ Solution

Challenge 2: Collection or Environment Variable?

For each, say whether it should be a collection variable or an environment variable, and why: (a) baseUrl, (b) an API version path segment used identically in dev, staging, and production, (c) a per-environment API key.

Goal: Practice applying the "shared everywhere vs. differs per environment" test to concrete variables.

→ Solution

Challenge 3: Design a Chained Sequence

Describe the request chain (using this chapter's "Set as variable" pattern) needed to: create a new order, then immediately fetch that order's status using the ID the creation response returned.

Goal: Practice identifying which value needs to flow from one response into the next request's URL, not just its headers.

→ Solution

⚠️ Gotcha: Exporting an Environment With Real Secrets Still Baked In

Sharing or backing up a Postman environment often means exporting it as a JSON file — and that export includes every variable's current value, not just its name. An environment holding a real production API key or a live auth token, exported and then committed to a shared repository or sent over chat, leaks that secret exactly like the hardcoded-credential mistake covered elsewhere on this site — the fact that it's "just a Postman file" doesn't make the value inside it any less sensitive. Treat an exported environment file with real production values the same way you'd treat a .env file: never commit it, and prefer Postman's built-in "secret" variable type (which masks the value in the UI) for anything genuinely sensitive.

🎯 What's Next

The next chapter is Postman Scripting & Automation — pre-request scripts, test scripts with pm.test, running a whole collection unattended with the Newman CLI runner, and mock servers.