Postman Enterprise: Behind-the-Curtain Features Used by Auto and Tech Industries

Today, almost every industry—from automotive to healthcare—is taking advantage of the utility and efficiency of APIs. Inspired by all of the different use cases we see, and wanting to make it easier for companies along their API journey, the Postman solutions engineering team has created demos using fictional companies as examples. Over the coming weeks, we’ll be releasing a series of blog posts and videos based on these demos—all to show how users of the Postman Enterprise plan can leverage the Postman API Platform to address challenges specific to their industry.

To start this process, our research team put together some incredible reports around current API usage and challenges in different industries. By combining this information with the firsthand knowledge of solutions engineers who have experience in these industries, we felt we were in a good position to start laying out how companies might set up their Postman workspace to meet their needs. The Postman team then split up into squads led by an engineer with expertise in a particular industry and started thinking about how we could tailor each of these workspaces to the challenges and needs faced by businesses. As a technical enablement architect, I floated around through the teams to provide assistance building out their vision.

Though the specifics varied between use cases, there were a few features we knew we would implement across all teams because they benefit any business. We then laid out some guidelines for what we wanted to have in each demo environment. In this post, we’ll go over some of these features that lie beneath the surface of what is visible in a Postman public workspace but that are very useful in a team’s day-to-day activities. Then, we’ll see how businesses in the automotive and technology industries employ the features.

3 behind-the-curtain Postman features

SCIM

In smaller organizations of five to 10 people, setting up Postman for organizational use is fairly easy: everyone signs up for an account on their own, and any account provisioning is done on an ad-hoc basis. However, for larger organizations, this process requires a bit of finesse to preserve both security and sanity.

That’s why Postman Enterprise provides user provisioning through our SCIM API or through an integration with Okta, which allows administrators to provision and deprovision Postman accounts easily and in a more cohesive and controlled manner. Using the SCIM API, a little Postman scripting, and the Collection Runner, a business can set up its team of 100 Postman users in minutes.

User groups 

With Postman user groups, admin users can assign a set of permissions to multiple users at once. Though it’s an Enterprise plan feature, it doesn’t require a massive team to be immediately useful; it can benefit teams of even just a couple dozen people. Assigning permissions to teams based on their role gives confidence to resource producers that their work won’t be interrupted or altered unknowingly or accidentally, and confidence to resource consumers that they won’t mess anything up by clicking around and exploring.

Some examples of common groups and their use cases we explore in our demos across industries are:

• Frontend developers: These users may not be involved in defining the APIs so they may not need editor privileges on APIs or collections, but they should be able to create new elements in a workspace (like a frontend-specific environment for testing and development).
• Backend developers: These users are most likely to create and edit APIs and collections.
• QA Team: The team in charge of testing needs an editor role on collections to be able to add tests, but might not need editor access on APIs.

Private API Network

The Private API Network allows teams to share APIs with anyone else under their team’s plan in an organized, discoverable way. With the recent release of Postman v9 in September 2021, we added even more functionality to the Private API Network for both API producers and consumers. Now, each API version is its own distinct entity, with its own documentation and status tag, indicating whether an API is in its infancy (“in testing,” “in design,” or “in development”) and maybe not quite ready for primetime use, or is vetted and ready for the spotlight (“in production”). API producers also have the option to keep APIs off of the private network until they’re ready to be shared, and can sort APIs into folders for easy navigation when they are ready to publish. Though this aspect of our work isn’t visible from the public workspaces, it’s an important part of an organization’s setup and we wanted to make sure it was something we could show during demos.

Now we’ll dive a little deeper into the specific challenges faced by two key industries and how Postman Enterprise’s capabilities address these needs. In this post, we’ll explore the automotive and technology industries, but keep an eye out for future posts covering healthcare, retail, finance, and insurance.

Automotive industry

When laying the groundwork for our automotive industry demo public workspace, we were inspired by Postman Chief Evangelist Kin Lane’s Breaking Changes interview with John Musser, the director of data and analytics for Ford Autonomous Vehicles. In the episode, John and Kin discuss some of the ways that vehicles and APIs are interacting, opening the door for many service integration and automation use cases. We built our demo workspace around the idea of a team of developers connecting to every possible car sensor, and called our team and the workspace, aptly, “Connected Car.”

Data privacy and security

Of course, with the level of connectivity mentioned above, comes an unbelievable amount of data. Automotive companies have the responsibility to keep all this data private and secure while enabling partners to build integrations—certainly no easy task. Though Postman isn’t a data storage platform, there are safeguards that can be utilized to make sure the API development and testing are only exposing the necessary data. We’ll take a deeper dive into security in the next post of this seires, but utilizing the Postman token scanner, maintaining good variable storage practices for sensitive data, and keeping an eye on which data gets shared outside of the organization are crucial proactive practices teams can take to keep data secure within the Postman platform.

Industry pressure

Industry pressure also plays a role in software development: automakers and integration partners need to keep up with the evolving landscape and develop APIs efficiently. To make sure time and effort aren’t wasted, businesses use the Private API Network to document teamwork and make sure efforts aren’t being duplicated. Postman’s new two-way git sync integration also enables teams to keep a single source of truth for both API spec files and collections, eliminating the “which version?” confusion and allowing collaboration among teams who may be using the API spec in multiple places.

Testing and safety

As you can probably imagine, it’s pretty vital that software responsible for controlling large vehicles works exactly as expected. Here are a couple of different types of testing that we focused on for the automotive industry:

1. Schema checks: As we mentioned earlier, third-party integrations are becoming a bigger part of the connected car experience as the industry veers toward an API-centric standard of operation. Anyone integrating with an automaker’s API standard needs to make sure it is implemented as intended. For example, it can be easy for wires to get crossed and an ID variable documented as a String get implemented as a number, so it is crucial that there are automated checkpoints ensuring correct compliance before partner APIs get put into production. To implement a schema-check test in Postman, we manually defined our agreed-upon schema as a variable and created a test to compare our response against it. But to make this process even more portable, we could host our schema somewhere, import it, and implement the same process to save ourselves from repetition.
2. Status code and expected value checks: This is a bit simpler than a full-fledged schema check. By testing that we are getting back our expected response status code and checking that values align exactly or fall within an acceptable range, we can quickly catch any values that might throw our systems for a loop. The “snippets” pane available in the Tests tab in Postman is a great source for browsing and easily implementing any tests that you think might help your QA processes.

Technology industry

When we dove into the planning process for our technology industry demo public workspace, we knew we really had to narrow our focus. Being a technology company ourselves, we’re very aware of the many challenges faced by companies in this space, and we know how widely the use cases can differ. We ended up creating a fictional security-focused company that we name NOVA Security, and we used it to address the following real-world concerns.

Developer experience

As our fictional company was in the business of providing APIs as a service, we needed to make sure that the developer experience was world-class. For our API, we focused on building out the documentation in the Postman interface, as well as providing a link to published documentation. We will cover different types of documentation in more depth in an upcoming post, but in short, we made sure to give an overview of resources available in the workspace, and kept narrowing our focus and level of detail as we documented at the collection, folder, and request levels. Adding example responses to be used with our mock server can be considered another form of documentation, and also helped to reduce the “time to first call,” a crucial metric for API adoption and satisfaction. Stay tuned for more strategies behind these elements in upcoming blog posts.

Though it may seem tedious to spend so much time on documentation, with Postman’s environment and collection forking capabilities, the time you spend on the frontend setting up your resources reduces the time for the consumer to get up and running on the backend. When an API consumer—either internal or external—comes to your workspace to fork a collection, they can pick up exactly where you left off and start making calls immediately, reducing time spent in developer portals and question-asking limbo.

Consistent expected API patterns and governance

As many technology companies deal mostly in digital assets, it’s important to establish consistent patterns for production and governance of resources. Much in the same way a physical goods company might have an established and documented method of crafting their product, digital companies may look to implement a similar set of guidelines. We touched on user groups and how it’s important that your API team has the necessary permissions. But how do we go beyond individual contributor guidelines and ensure our teams are operating in a manner consistent with company expectations?

Here are a few things we focused on for our technology demo workspace:

• Naming conventions: As large teams start to accelerate their pace of creation in the Postman platform, there comes a need to organize and manage assets. One way we organized our multiple workspaces was grouping them by focus, and naming each workspace starting with the general subject in brackets, followed by the more specific focus, which makes for easy sorting in the workspace dropdown. For example: “[Integrations] Nova Security API”, and “[QA] Newman Bitbucket CI/CD.”
• Linking to a version page: Make sure all resources associated with a particular API are linked to that API’s version page. The newly redesigned API version page allows linking everything from documentation, mock servers, and environments to integrations like CI/CD and deployments. Keeping resources linked to a version groups them together and prevents confusion when naming conventions may fail.
• Governance collections: A not-so-visible third aspect that can aid in the governance journey, these are collections created to ensure other collections follow a set of guidelines (a little meta to think about, we know). An example of one of these governance collections is the Governance – Full Lifecycle collection put together by Kin Lane. It defines a set of tests for automatically checking that your APIs and collections comply with a set of guidelines: checking everything from “do all of our parameters have associated descriptions,” to “do we have a monitor for our security testing collection?” While steps like this are not a necessity for a successful Postman setup, they can help ensure consistency across an organization.

We hope this was an informative look at how two different industries might take advantage of the Postman API Platform, and that you’ll try out these features and approaches with your own Postman team. Have a tip we missed or an insight on how your industry is uniquely utilizing a Postman feature? We’d love to hear about it in the comments below.