Postman Environments and Variables

Build the mental model

A collection becomes painful to maintain the moment you need more than one server. If every request hardcodes a URL, moving from development to staging or production means editing each one by hand — and it's easy to forget one. Environments separate what a request does from where it points.

An environment is a named set of key-value pairs. Development defines baseUrl as your local address and a test token; Staging defines the same keys pointing at a staging server; Production does the same again. Switching the active environment changes what those keys resolve to — not the requests themselves.

Requests reference these keys with placeholder syntax: {{baseUrl}}/users instead of a hardcoded URL. The same substitution works in headers, query parameters, and bodies — so an auth header can read Bearer {{token}} without the real value ever appearing.

Environment Variable

A named placeholder (like baseUrl or token) defined per-environment in Postman, referenced in requests as {{name}} and resolved to that environment's actual value only when the request is sent.

ENVIRONMENTS FEEDING THE SAME REQUESTS
--------------------------------------
DEVELOPMENT            STAGING               PRODUCTION
baseUrl: local           baseUrl: staging       baseUrl: prod
token:   dev-key         token:   staging-key   token:   prod-key
       \                      |                      /
        \                     |                     /
         v                    v                    v
            ONE SET OF REQUESTS, SAME FOR ALL THREE
            GET     {{baseUrl}}/users
            HEADER  Authorization: Bearer {{token}}

Connect it to a real scenario

Imagine a "Users API" collection with requests built around {{baseUrl}}/users. During development, Development's baseUrl points at http://localhost:3000 with a throwaway test token. To check staging, you switch environments — baseUrl now resolves to a staging URL and token to a staging credential — without touching a request.

The same pattern extends to anything that differs by environment: Production might use a different token format or an extra required header. None of that logic lives in the requests — it lives in whichever environment is active when you hit send.

• Before sharing: open the exported environment file and check every value.
• Replace any real token or password with a placeholder like <your-token-here>.
• Never assume an exported environment is 'just config' — treat it like a credential file.

• Environments separate what a request does from which server it currently targets.
• Variables like {{baseUrl}} and {{token}} are resolved from the active environment only when a request is sent.
• Never commit or share an exported environment file that still holds real secrets — treat it like a password file.

Try the working example

// Illustrative only — represents Postman environment variable sets,
// not real credentials. {{baseUrl}} and {{token}} are placeholders a
// request uses; Postman fills them in from whichever environment is
// currently active.

const developmentEnv = {
  baseUrl: "http://localhost:3000",
  token: "dev-test-key-123",
};

const stagingEnv = {
  baseUrl: "https://staging.example.com",
  token: "staging-test-key-456",
};

const productionEnv = {
  baseUrl: "https://api.example.com",
  token: "<never store the real value in a shared file>",
};

// A request always looks the same, regardless of which environment
// is active:
const request = {
  method: "GET",
  url: "{{baseUrl}}/users",
  headers: { Authorization: "Bearer {{token}}" },
};

This code is not run — it illustrates shape, not real execution. Switching Postman's active environment dropdown from Development to Staging would change what {{baseUrl}} and {{token}} resolve to when the request above is sent; the request text itself never changes.

Postman Docs — Variables — API Integration & Webhooks