Deliver your Apps Faster with PingOne for Customers and Postman using Collections, Environments, and Scripts

It may not make sure you get your bills and ad circulars delivered to your mailbox every day like a real postman, but the Postman application can still be a big help if you’re a developer working with APIs. Since the popularity of APIs has taken off, developers have been looking for ways to make API development faster and easier. 

Postman is one popular tool that has emerged to help you be more efficient. Essentially, it gives you a middle ground between doing all of your API development on the command line and doing all of it in an application interface. API development in the command line can get messy quickly, and doing it all in the application interface doesn’t translate easily into usable code. Postman breaks down all components of an API request into a UI, making it easier to replace variables, make small changes and iterate quickly, while having an easy path to translate it all into code. 

But I’m not just here to talk about Postman—I’m here to help you get your apps involving identity services out faster. So I’ll cover three things in this blog:

• How to use Postman environments and collections efficiently
• Identity and access management, it’s importance and how it relates to APIs
• How identity APIs and Postman fit together, with some examples from PingOne for Customers.

Two of Postman’s most important features are collections and environments. Used correctly, they can drastically improve your efficiency when doing API development. You can even pair them with scripts to further automate and streamline your development process. 

Collections allow you to group API requests together, similar to how a folder can group files together on a filesystem. That means you can keep requests that are often run together in the same place for quick access. There aren’t any specific rules you need to follow for how to group requests together into a collection, so there are no limits to how it can be used. Structure it however works best for you! 

If you need some ideas, here are some common organizational structures:

1. Group together requests that must be done in a specific order to accomplish a task.

For example, if you want a way to easily update a user’s profile, you first have to make a call to get the user ID, then call the request that updates the user’s profile. Or, perhaps you need to get an access token, which will then allow you to access a protected resource. By grouping the two requests together, you can do what you need to do faster.

2. Group together different requests that allow you to do the same thing.

For example, to get an access token, you might be able to use either a GET or POST request. If you group the two together, you can see all the different methods in one place and choose the one appropriate for your configuration or situation.

3. Group together requests based on their endpoint.

For example, you could put all requests that target the /Users endpoint into a collection separate from the ones that target the /Applications endpoint, so it’s easily apparent which requests to use for which situation.

Environments in Postman allow you to create variables and assign them values, which can then be substituted in when the API request is made. For example, you can use a variable for a team ID called “teamID” in the URL rather than some long string like 1020130RSAFJASDF0991309LKASFD-9312KLJAS9D90F. Postman will replace the variable name in the API request with the actual value of the teamID, which saves you time having to go track down that string of gibberish and paste it in (or memorize it.) And the variables will update automatically when you switch between environments so you don’t have to change your requests, only specify the environment. 

A typical case where environments come in handy is when you have more than one value for a particular variable name. If you’re making requests for two different users and you’ve stored them as values in different environments with the same variable name, it’s simple to just switch environments when you want to switch which user you’re testing on.

Again, there are no strict rules on how to group things, which means you get to do whatever makes the most sense to you and whoever is going to use the environment. Here are a few possibilities:

1. Have an environment for each user

This is the example I described above—by storing each user’s user ID, group ID and the specific URL for updating them in a different environment, you don’t have to change the values individually in your API requests, just change the environment.

2. Have an environment for each application

If you have a client app and a worker app, storing the data for each ID in different environments can help you make those API requests faster—just use “appID” as the variable name associated with two different values in two environments.

Let’s leave Postman for a second and talk about identity and access management (IAM). Identity and access management is critical to any app. It provides capabilities from registration, login, account recovery, profile management, and other capabilities that are in almost every app—but not always very fun to develop. Identity solutions are becoming more and more pervasive and important, especially for developers building applications for customers. You need to make sure that the right people get access to your app’s data whenever they need it, keep track of customers to personalize their experience within your app, and do all of this while keeping your app and the information within it secure from unauthorized users and hackers.

Identity and access management (IAM) helps you do all of that. Common IAM capabilities you’ll probably need to consider are:

• single sign-on, to allow customers to go between different sites without having to log in every time
• end-to-end encryption to keep identity data safe
• user registration
• authentication to make sure users are who they say they are
• self-service and profile management to put customers in control of their data
• account recovery
• multi-factor authentication to add another layer of security when necessary

Identity-as-a-service (IDaaS) solutions like PingOne for Customers are a relatively new way of providing some or all of the above mentioned identity capabilities as an easy-to-use cloud service. IDaaS provides the same benefits of any SaaS solution you might consume, including outsourcing the burden of building the capabilities from scratch and managing a system in-house.

So that all sounds great, but where do APIs and Postman fit in? Simple: the best IDaaS solutions are API-based, so you can make API calls from within your code and have the identity services you need provided to you. The specific form of APIs you’ll use in this case are called REST APIs. And using the Postman capabilities I talked about above can help you make those API requests faster and easier, so you get all those great identity services with minimum effort.

Identity APIs in Action: Access Token Use Case

Remember, collections are a nice way of keeping things logically separate, so we’ve provided sample Postman collections to help you get your app implemented with identity services from PingOne for Customers quickly. In our sample collections, things are broken down into Authentication API and Management API. Each of those are further broken down into specific tasks like application management or user registration flows. You don’t have to structure them in the same hierarchy that we have, but it may make sense to do it this way.

So let’s take a look at how this would work. I have a collection of two requests that I often run with PingOne for Customers. I want to look up a user ID, but first, I need to retrieve an access token, which proves I have the right to do so.

1. So here’s my collection, in which I’ve grouped the two related API requests:

2. First I get my access token, which you can see here:

3. Then, using the second API request in my collection, I look up a user by their email to get their ID:

These two requests make use of many environment variables like “authPath”, “apiPath”, “envID”, and so on. The variables will be filled in with their values by Postman when the request is run.

If we open the console for the first request, we can see the values filled in:

For example, authPath filled in with the following: “auth.pingone.com”. You can see it towards the beginning of the request url at the top after “POST” and next to “Host” in the “Request Headers”.

This is what it looks like in my environment named P14CPostmanBlog: 

Postman Scripts

After completing a request, you can run scripts to use information returned from that request. Below I’ve shown two examples of how you can automatically update environment variables that were returned from the request, rather than manually inputting them.

Example 1: The following script runs after my example request to retrieve an access token. After I get the access token, the script looks for the “access_token” variable from the json version of the response. Then, it updates the environment variable with the new value taken from the response.

Example 2: This example script updates the “userID” environment variable from the first user found. After taking the ID from the response, the script fills in the “userID” environment variable:

There are all sorts of ways that Postman collections and environments can help you speed up your API development and take advantage of API-based identity services. 

PingOne for Customers is a custom identity and access management platform in the cloud that provides a robust set of APIs. We’ve exposed all of those APIs in an easy to use Postman collection that you can download. I encourage you to check out the sample Postman collections and see how easy identity can be for yourself. All you’ll need to do to get started is: 

1. Sign up for a free trial of PingOne for Customers
2. Download the sample Postman collections
3. Put your unique variables in to Postman. 

I’m always monitoring the PingOne for Customers community, so feel free to post a comment or question there if you need help using the APIs.