Postman – Using Environments and Tokens

Rick Herrmann

Postman is an incredibly  useful tool for testing API’s.  I’ve been using it for a few years now and have found some features that make it a breeze to work with when it comes to secured API’s. It’s good for handling different environments as well.

Login and Tokens

A common pattern we use with our API’s is to use Javascript Web Tokens(JWT’s) for authentication. To work with this in Postman, I typically have a /login post call which returns a token. Then for any other calls to that API, I manually copy the returned token, and set the Authorization header to “Bearer <token>”. Although this works, it’s a pain when the login token expires and I have to copy a new token to the Authorization header for every saved API call.  For an API where you have a lot of endpoints saved, updating all the Authorization headers can become tedious.

However, there is a way to make the API token update happen automatically. What I’ve found is that by using a combination of postman tokens and the testing functionality, we can capture the token from the login call and automatically propagate it to every saved endpoint in the collection.  The first thing to do is to create an Environment in Postman:

First we add our ‘Environment Variables’ to our environment. So in this case I have setup a variable called token, and also set the value.

To access the environment variable, you use the {{variable_name}} syntax. So in this example, we can set the Authorization token to “Bearer “ + whatever the value of the token is.

At this point we have replaced the specific token value with an environment variable.  But – how do we change the environment variable value when this token expires and we login again and get a new one?  Postman has a testing feature where you can write javascript to examine values returned from an API call and make assertions.  In this case, we can hi-jack the “Tests” functionality and use that same post-call hook to run a script to set the value of the “token” variable.  In this example, the Tests script is running after the Login API call, which returns the token we want to store.

So by using “Bearer {{token}}” as the Authorization header value in all of my secured API calls, I can call my Login endpoint, and then immediately use all of my other saved API calls with no change and use the just returned token.  Huge time saver.

URL’s and Changing Environments

Another way to leverage Postman tokens is when you have to change between URL’s – for example testing on localhost and then testing perhaps on a staging server. Similar to JWT token updates, we can create an environment variable for the root-URL of the API we want to target.  However, instead of using a Postman test to change the value, we can use Postman environments to quickly change between two endpoints.  The current environment is set here:

Token values can be defined for each environment. Here we have a token called URL with a localhost value:

I also setup an environment with a token called URL that points to an Azure endpoint.  By selecting this environment, we get a new value for the URL token:

Of course – the key to making the URL changeable by switching environments is to include {{url}} in the URL:


Postman has always been a great tool for testing and building out API’s, but by also using a combination of tokens and environments, I think you’ll find it much easier to work with.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s