Environments in Postman

Environments allow you to run requests and collections against different data sets. For example, you could have an environment for development, one for testing, and another for production. You can use variables to pass data between requests and tests, for example if you are chaining requests using a collection.

Environments in Postman are key-value pairs of variables. Each variable name represents its key, so referencing the variable name allows you to access its value.

To create an environment, use New > Environment, or the Manage environments button in the top right of Postman, and click Add. Give your environment a name , such as “Testing”—you can add variables at creation or later, by editing the environment.

To select the environment to run your requests within, use the drop-down at the top right of the Postman app.

Environments

Your requests will run with the data variables listed in the environment you have selected.

You can duplicate, delete, download / import environment JSON, and share environments with collaborators in Manage Environments. Sharing environments allows you to let other people run your requests against the same data sets.

Manage Environments
Environments

Variable scopes

Postman supports the following variable scopes:

  • Global
  • Collection
  • Environment
  • Data
  • Local
Variable Scope

If a variable with the same name is declared in two different scopes, the value stored in the variable with narrowest scope will be used—for example if there is a global and a local variable both named username, the local value will be used when the request runs.

Choosing variables

Variable scopes are suited to different tasks in Postman:

  • Global variables allow you to access data between collections, requests, test scripts, and environments.
    • Since global variables can create confusion, you should only use them sparingly—for example to quickly test something or when your project is at a very early prototyping stage.
  • Collection variables are available throughout the requests in a collection and are independent of environments, so do not change based on the selected environment.
    • Collection variables are suitable if you are only using a single environment, for example for auth / URL details.
  • Environment variables allow you to tailor your processing to different environments, for example local development vs testing or production. Only one environment can be active at a time.
    • If you only have one environment, using collection variables is more efficient.
  • Local variables are temporary, and only accessible in your request scripts. Local variable values are scoped to a single request or collection run, and are no longer available when the run is complete.
    • Local variables are suitable if you need a value to override all other variable scopes but do not want the value to persist once execution has ended.
  • Data variables come from external CSV and JSON files to define data sets you can use when running collections via Newman or the Collection Runner.
Variable Scopes