Collections, Environments and Variables in Postman
The three features that turn Postman from a scratchpad into integration documentation a whole team can actually reuse.
The most common problem when testing an integration: the same request has to run against Sandbox and against Production, with different URLs and credentials. Type both by hand and sooner or later someone fires a Production request believing they are in Sandbox.
Collection
A Collection is a folder of related requests — for example every endpoint that touches Items. It works as living documentation: a new developer does not have to ask which endpoint is in use, they open the Collection and run it.
Environment
An Environment holds the values that change with the target: base URL, account ID, token. Create one for Sandbox and one for Production, then switch with a dropdown. The request stays the same; only the target moves.
{{base_url}}/services/rest/record/v1/salesorder/{{order_id}}
# Environment: Sandbox # Environment: Production
base_url = https://1234-sb1... base_url = https://1234...
order_id = 15821 order_id = 90312Variable scopes and which one wins
| Scope | Applies to | Typical contents |
|---|---|---|
| Global | The whole workspace | Values that rarely change |
| Collection | One collection | API version, base path |
| Environment | The selected environment | base_url, token, account id |
| Local / runtime | A single run | Values produced by a script |
When the same name exists in several scopes, the narrowest wins. Local beats Environment, Environment beats Collection, Collection beats Global. This is often behind the complaint that a value was changed but nothing happened — the old value still lives in a narrower scope.