Pdf Variables

[Yufei Labbe]

Variablesenable you to store and reuse values in Postman. By storing a value as a variable, you can reference it throughout your collections, environments, requests, and scripts. Variables help you work efficiently, collaborate with teammates, and set up dynamic workflows.

A variable is a symbolic representation of data that enables you to access a value without having to enter it manually wherever you need it. This can be useful if you are using the same values in multiple places. Variables make your requests more flexible and readable, by abstracting the detail away.

For example, if you have the same URL in more than one request, but the URL might change later, you can store the URL in a variable base_url and reference it in your requests using base_url. If the URL changes, you can change the variable value and it will be reflected throughout your collection, wherever you've used the variable name.

The same principle applies to any part of your request where data is repeated. Whatever value is stored in the variable will be included wherever you've referenced the variable when your requests run. If the base URL value is -echo.com, and is listed as part of the request URL using base_url/get, Postman will send the request to -echo.com/get.

Use your Postman Vault to store sensitive data as vault secrets, and reuse them in your local instance of Postman. Only you can access and use your vault secrets, and secrets aren't synced to the Postman cloud.

Use environments to group sets of variables together and share them with collaborators, for example if you use one set of config details for your production server and another for testing. See Group sets of variables in Postman using environments for more on how you can incorporate environments into your team workflows.

Postman supports variables at different scopes, allowing you to tailor your processing to a variety of development, testing, and collaboration tasks. Scopes in Postman relate to the different contexts that your requests run in, and different variable scopes are suited to different tasks.

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 variable named username and a local variable named username, the local value will be used when the request runs.

Initial value is a value that's set in the element (collection, environment, or globals) where the variable is defined. This value is synced to Postman's servers, and is shared with your team when you share that element. Setting an initial value can be useful when sharing elements with teammates, but note that data in an initial value will also be shared with others, and potentially with the world.

If you need to store and reuse sensitive data, it's recommended to use Postman Vault to store it as vault secrets in your local instance of Postman. Only you can access and use your vault secrets, and vault secrets aren't synced to the Postman cloud. If you want to share sensitive data with collaborators or access it in scripts, you can store it in an environment as a secret type variable.

Current value is used when sending a request. These are local values, and aren't synced to Postman's servers. If you change a current value, it won't be persisted in the original shared collection, environment, or globals.

Secret type masks the initial and current values for all workspace members and can be used to prevent unintentional disclosure of sensitive data, including API secrets, passwords, tokens, and keys.

It's recommended that you use your Postman Vault to store sensitive data, such as API keys, as vault secrets. Only you can access and use your vault secrets, and vault secrets aren't synced to the Postman cloud. If you want to share sensitive data with collaborators or access it in scripts, you can store it in an environment as a secret type variable.

You must have Editor access on a workspace (for global variables) or environment (for environment variables) to control variable type. Editors can change the variable type from secret to default at any time, and vice versa. When you change a variable's type from secret back to default, you must confirm by selecting Change type.

Editors can change a variable's initial values, which are shared with collaborators, by selecting the eye icon next to the variable, then selecting the initial value. All collaborators can change a variable's current values by selecting the eye icon , then selecting the current value.

The environment quick look shows the selected environment along with global variables in your workspace. You can edit the current value for an existing variable inline by selecting the value. To add a variable, select Edit next to the global section.

The environment quick look shows the selected environment along with global variables in your workspace. You can edit the current value for an existing variable inline by selecting the value. To add a variable, select Edit next to the environment section.

If you don't have Editor access to a collection, you can select Request Access. Without Editor access, you won't be able to add new collection variables, update initial values, or persist values. You can edit the current value for local use, override the collection variable by using an environment variable with the same name, or request Editor access to the collection.

You can use double curly braces to reference variables throughout Postman. For example, to reference a variable named username in your request authorization settings, you would use the following syntax with double curly braces around the name:

Using pm.variables.get() to access variables in your scripts gives you the option to change variable scope without affecting your script functionality. This method will return the variable that has the highest precedence (or narrowest scope).

The Collection Runner lets you import a CSV or a JSON file, and use the values from the data file inside requests and scripts. You can't set a data variable inside Postman because it's pulled from the data file, but you can access data variables inside scripts, for example using pm.iterationData.get("variable_name").

When you edit global, collection, and environment variables in Postman, there is a Current value that you can choose to Persist or Reset for individual variables. You can also select Persist All or Reset All to apply this setting to all variables. These enable you to control what happens within your local instance of Postman, independently of how the data is synced with anyone sharing your workspace, requests, collections, and environments.

When you create or edit a variable, you can enter both an initial and a current value. When you create a new variable in Postman, if you leave the current value empty, it will autofill with the initial value. If you specify a current value, it will be local to your instance. The Persist option pushes your current value to the shared data, updating the initial value to match the current value.

If you don't have Editor access to an environment, you can't edit the initial value of an environment variable. You can edit the current value, and your edit won't be visible to anyone sharing your workspace.

Using Persist makes your current value sync with Postman's servers and be reflected for anyone sharing your collection or environment. To reset your current local values to reflect the initial shared values, use Reset.

Your local session in Postman can use values that are transient and visible to you, but aren't synced or shared with your team. This lets you develop and test using private credentials or experimental values, without risk of exposing these details or affecting others on your team.

For example, your team could have a shared API key and individual API keys. You could do experimental development work locally using your personal key, but use the shared key for team collaboration. Similarly, you could have a variable that represents exploratory work you're doing locally but aren't ready to share with the team. You can later choose to persist the local data so that others on your team can also access it.

For example, for the request -echo.com/get?customer_id=cust_id, Postman expects to be able to find a definition for cust_id in the environment the request uses, in the collection the request is saved in, or at the global level. If Postman doesn't find a definition for cust_id in one of those scopes, it flags the variable as unresolved. If you send a request that includes an unresolved variable, the request might fail.

When you are working on an API request, Postman highlights unresolved variables in the URL builder, the Params tab, the Authorization tab, and the Headers tab. Postman highlights unresolved variable text in red. For more details about the error and how to resolve it, hover over the unresolved variable.

Variables that are defined programmatically in a script are resolved differently depending on the variable scope. This means that unresolved variables will also be handled differently. Local variables that are set programmatically using pm.variables.set may appear to be unresolved since they're not stored and are only used at runtime, but if they're set and used correctly the request will still run successfully. Environment, global, and collection variables that are set programmatically are saved for later use, so they will resolve if they're set and used correctly. Depending on how an unresolved variable is used in a script, you may receive a 400 Bad Request error response from the API, or Postman may be unable to send the request at all. Open the Postman Console to help identify unresolved variables in your scripts.

3a8082e126