Reducing Copy/Paste in Postman

Postman is a tool for helping develop APIs faster.

Copy/Paste… Ugh

While testing some of the back­end for a new website that the rest of the interns and I are working on, I got fed up with having to copy/paste authentication codes in Postman every hour when my token timed out. So, I decided to mess around and see if automating the authentication process was possible in Postman. Turns out it is! I’ll show you how to automate it by using the login process the interns have been using for this project as an example, along with a few other cool things.

Here’s an example of what one of our requests using an authentication token looks like.

And here’s an example of the POST request I have to send to login every hour.

When I send the request, this is the response I get back.

I have to copy the X­Auth­Token string into all my new requests if I want them to work. Then, if I go into my history and use an old request, half the time it has an old auth­token that I forgot to replace, so when I run it I get an invalid access error back and have to copy the new one in and run it again. Very annoying, especially when I have to repeat this every hour!

Environment Variables to the Rescue

To fix this, we can make it so that Postman automatically creates an environment variable called X­Auth­Token (or whatever you’d like to call it!) and saves the value from the login response into it. To do so, click on the ‘Tests’ tab in your login POST request (two tabs to the right of the ‘Body’ tab). Enter the following code into it:

var data = responseHeaders

postman.setEnvironmentVariable (‘X­Auth­Token’, data[‘X­Auth­Token’])

This will save the headers of the response into a data variable, and then access the X­Auth­Token header and save it to whatever you want to name the environmental variable (in my case, also ‘X­Auth­Token’ in the code). If the variable doesn’t exist, it will make it and then save the data! Otherwise it will just replace the old data.

Set Up a Named Environment

Now, it’s helpful to set up a named environment for the variable to be saved to. I don’t think it’s strictly necessary in order to save the variable, but you can do some cool stuff with environments that I’ll show you in a bit. So, to set up a new environment, click on the tab in the upper right corner that says ‘No Environment’. This is, of course, assuming you haven’t made an environment already.

Click on ‘Manage Environments’. It should bring you to this screen.

Click on ‘Add’, and name your new environment. Click on ‘Add’ and then exit the environment manager window. You should see your new environment in the environment tab in the upper right now!

Now, go send your login POST request, now with your added code. If you click on the eye symbol in the upper right, it should show you all your active environmental and global variables. The authentication token from the response should be saved up there in a new variable!

Now, in order to access that variable, all you have to do is replace the string you used to have in your request headers with:

{{authVariableName}}

If you run it, it should work!

Now, this is useful, but right now you’re still copying and pasting something, even if it is shorter than a very long authentication code.

Create a Collection of Requests

However, what you can do is save requests to a collection. Using this, you can save all the requests you regularly make to a collection, with the variable already saved in each request. All you’ll have to do is click on the request you want, change the body and any other variables you want, and run it. No more copy pasting! So, go to the main Postman screen, and either choose a request from your history or draft up a new one.

Hit ⌘ + S (or ctrl + S, I guess, if you’re on Windows or something…) to open up the save window. Name your new request at the top, and name your new collection at the bottom. Hit ‘Save’, and it will create your new collection and insert your new request into it.

You should see them under the Collections tab.

If you’d like to add a new request to the Collection, repeat the same process, but instead of naming a new collection, search through the saved collections and choose the one you just made.

Alternatively, you can hover over a saved request, click on the ‘…’ button, and select ‘Duplicate’. You can then just choose the ‘Edit’ option on the duplicated request to rename it, and then edit it.

Testing All Requests in a Collection

Now, the really cool part about making a collection, along with all your favorite requests saved in one place (with authentication automated!), is that you can run them all at once in a sequence. Click on ‘Runner’ in the top left corner, and it should open up a new window!

Select the collection you want to run, and choose the environment you want to use for the run.

Now, hit ‘Start Test!’ You should see all of your requests run in sequence!

This is really helpful for testing all requests at once after changes to the API. Just remember to format your requests in a way that makes sure that they’re all are successful if they’re actually working, ideally cleaning up after themselves, especially if you’re doing database manipulation. You can also write tests (in the same tab that we added in the authentication code in) that run after a request, and which can be viewed by clicking on the ‘i’ symbol under a test.

Use Variables and Environments to Simulate Different Users

Now, there’s one last cool thing I found that you can do to speed up your testing. When testing, sometimes I need to make sure that admins can access certain URIs, while normal users cannot. To do this, I need to switch logins by changing the body of my login request, logging back in, testing, and then changing the body back to go back to my admin login. Kind of annoying, right? Turns out, you can also automate this with environment variables! First, here’s what my normal login body looks like.

Now, go back to your environment that you made, and make two new environment variables named Email and Password (or whatever variables you’d like for your login process). For their values, enter your email, password, and any other relevant data, with quotes surrounding them if they normally have quotes. I made the mistake of not surrounding them at first… You should be able to see your new variables in the variables viewer.

Now, go back to your login request header, and replace the values with your new variables, surrounded with double curly braces.

Now, if you’d like to login as other users, just duplicate your environment in the environment manager (with the little page button next to ‘Share’), rename the new environment to whatever you’d like, and change the variables to your new login info. Now, if you run the login request, it will pull from the new values in your new environment, and login with your other user! No copy/pasting required, just a quick selection from a drop­down menu. (Ignore the typo in the Email variable, I fixed it before running it!)

The user wasn’t able to access the URI, just as it’s intended. And that’s it!

Some Final Tips

A few last notes: if you run into trouble, make sure you don’t have global variables with the same name as environmental variables. Global variables take precedence over environmental variables. Also, if you’d like to share your collection with other team members, hit the ‘…’ button next to your collection, and choose ‘Share’ or ‘Export’, whichever works best for you. Hopefully these shortcuts help save you some time and frustration.