Postman Environments: How to Control Access to Variables, Workflows, and More

Kin Lane

May 20, 2020

Many enterprises struggle to maintain control over their fast-growing and ever-evolving API infrastructure. At Postman, helping enterprises address these challenges is an ongoing top priority for us.

Exhibit A: the new release of role-based access control (RBAC) for Postman environments.

This new release—which I’ve dubbed “environment RBAC” for this post—allows enterprises to separate environment editors from those who only need view-only access to environments across team workspaces. This gives you another set of controls you can use to help define and stabilize the API lifecycle within your enterprise.

The introduction of environment RBAC complements Postman’s existing RBAC for teams, workspaces, APIs, and collections. This RBAC toolbox helps enterprises empower their API development teams while also improving how APIs are developed, delivered, and consumed inside and outside the organization.

Environment RBAC: How It Works

The new environment RBAC provides API development teams with two distinct roles to use when managing Postman environments:

• Editor Role: Users who are designated as editors can create and edit environments, helping define usable and reliable environments that other users can apply to their collections.
• Viewer Role: Users who are designated as viewers can view and put environments within workspaces to use, but can not make changes to the shared values that exist within an environment.

With this greater control over each user’s role, environment RBAC sets the stage for a more team-based approach to creating, managing, evolving, and applying environments. Rather than just having environments within personal workspaces, they can be more thoughtfully created with the rest of the team—and even the entire organization—in mind.

Getting Organized with Your API Environment Strategy

Environment RBAC is just one more way for API development teams to get more organized and thoughtful around how they use environments, putting them to work driving the overall API lifecycle. If you don’t yet have a formal strategy or plan in place for how your teams are creating and using environments, it can help to begin with a handful of areas to help you establish some momentum:

• Landscape: Spend the time to map out what environments already exist across your team workspaces and interview team members regarding how they use environments within their own personal workspaces. This will help you understand the current state of environment adoption in your enterprise.
• Purpose: Make sure each environment has a name that describes its purpose, ensuring some thought has been put into the creation, evolution, and management of environments across workspaces as part of your API operations.
• Team: Audit which users have access to the workspace environments, and then decide who should be editing, and who should just be viewing and putting environments to work.
• Audit: Regularly review what environments exist across team workspaces and document what the access levels are. This helps you evaluate how well teams are operating when it comes to the usage, evolution, and adoption of Postman environments.

It can be difficult to control access to what you don’t have properly defined; having a formal strategy, even if imperfect, is a good place to start. For many enterprises, environment usage often appears to be very chaotic and without clear intent, but with a little exploration and discussion with developers about how environments are used, you can quickly get a handle on how this critical component of the API lifecycle is leveraged on your overall API “factory floor.”

Putting Postman’s Robust Enterprise RBAC Toolbox to Work

As noted above, environment RBAC adds another dimension to the Postman RBAC stack, which now provides a total of five role categories and eleven total roles:

• Team Roles
  • Admin: manage team members and team settings
  • Billing: manage team plan and payments
  • Developer: access team resources and workspaces
• Workspace Roles
  • Admin: manage workspace details and members
  • Collaborator: work on team resources in a workspace
• API Roles
  • Editor: edit APIs directly
  • Viewer: view, fork, and export APIs
• Collection Roles
  • Editor: edit collections directly
  • Viewer: view, fork, and export collections
• Environment Roles
  • Editor: edit environments directly
  • Viewer: view and use environments

By stepping back and looking at the Postman enterprise RBAC stack, you can begin to see the potential for enterprises to bring order to the fast-moving and often chaotic world of developing and integrating with APIs. These RBAC roles and controls allow you to be more thoughtful in who can create and change the artifacts you are depending on for defining APIs and powering mocks, docs, tests, and other critical components.

Establishing Your Organization-Wide API RBAC Strategy

Hopefully this enterprise-grade RBAC toolbox—with the crucial new addition of environment RBAC—has gotten you thinking about how you can elevate your usage of environments and other Postman capabilities while eliminating some of the frustrating aspects all across your API operations. We believe it can be part of a larger enterprise strategy to help large organizations like yours further tame ever-expanding and evolving API infrastructures. In short, the Postman RBAC toolbox is built to not only help you map out your API operations, establish roles, and define access, but also to help you also audit, review, report on, and ultimately get the most out of your overall API infrastructure.

Initial vs Current Values for Variables in Postman

If you’re working with variables in Postman, you might be wondering “what’s the difference between initial value and current value”. Joyce Lin, Director of Developer Relations, explains in under a minute.