A simpler and local-first variables experience

At Postman, we are committed to delivering simple, practical and easy-to-use tools that make building and testing APIs efficient and effortless. Postman is also a mature product (we recently celebrated our 10th birthday!) with workflows that users rely on every day and are used to. However, mature products must evolve to meet the needs of modern developers and teams while keeping them as productive as ever.

Following the path of continuous improvement and simplification of our core workflows, last year, we overhauled how variables are used across Postman to aid in faster and more confident request sending. Today, we have re-examined how ‘variables are defined’ across Postman to address some of the confusing, frustrating, and potentially vulnerable aspects of creating variables. I’m excited to announce a redesigned variables table for collections, environments, and globals that not only brings in some exciting new capabilities to this surface area, but also addresses some of the recurring uhm, gripes, starting with the confusion around initial and current values.

Initial and Current Value

Just value, it’s cleaner.

A long-standing point of confusion—for our users and even for Postman engineers—has been the difference between “initial” and “current” values. This multi-value system also brought along extra actions, like persist all and reset all, which only added to the complexity. With the new variables table interface, we’re eliminating the ‘initial’ and ‘current’ terminology, as well as the need for separate columns for them. The updated interface is scoped down to its most basic constructs: a name and a value. That’s it, that’s all.

Local by default

All values defined in the ‘values’ column are stored locally by default. So, there’s no more accidentally pasting a sensitive value as the initial value and having it shared or synced to the cloud. The new interface seals off this possibility in favor of an approach that’s secure by design.

However, if you want a variable value to be accessible by your teammates, or want to use the variable with Postman’s cloud-based tools, such as Monitors or Collection Runner, you can share the value to the cloud explicitly with a ‘Share’ button. The interface has guardrails in place to ensure you’re never accidentally sharing a sensitive value.

Improvements

Variable descriptions: Use the description field to describe a variable’s usage, the possible range of values or where to get the value from. Just like you document your code to make it easier to reason about, you can now document your variables, too. Yay!

Autosave: One all-too-familiar experience with variables: you update a value, hit Send, and then realize the request used the old value—because you forgot to click Save first. This archaic manual frustration is no longer a possibility with the new variable interface. All changes to variables across all scopes are saved automatically.

Customizable layout: When we make core changes to a loved and mature product, we know that some users just want it to work the way it used to. So if you prefer to see the shared and local values side-by-side, we hear you, and we got your back. The new interface lets you customize your view to include a separate column for shared values as well as descriptions..

Start using the new experience today!

There’s minimal migration cost and no manual upgrade required. We have done our best to meet users where they are, and importantly, we have delivered these improvements without a breaking change or a major new release of Postman. This means that you can get all of these improvements by upgrading your version of Postman to at least 11.64.0 (postman.com/download) without having to change any of your workflows or complete an arduous migration.

Credits to the team

A change of this magnitude is always difficult, and difficult problems demand a strong and nimble team. The new variable experience is co-imagined by Udit Vasu with his diligent product and engineering outlook and brought to life by the talented cohort of engineers with Apoorv Gupta, Ankur Dengla and Rohan Grover contributing. Together, the API Client team believes that a delightful request sending experience is as much an engineering responsibility as it is a design one.

What’s next for environment and variables

As we continue crafting simpler and more powerful API execution experiences overall, we also want to ensure API developers are informed and assured that they’re executing their APIs in the right environments. We’re soon going to introduce the ability to mark environments with colored labels so teams can establish a clear affordance of the current environment being executed and the expectations of that environment (e.g. if you’re in prod, you should know that clearly!).

As always, we’re actively listening to and looking for your feedback to continuously improve the updates we ship. We have closed many of the most frequently requested issues (some of which were open for quite some time!) in our GitHub issue tracker this year and we recognize there’s always more to improve. As we say internally, our job’s not finished and we know we have more work to do. Our favorite feature is the next one. If you’d like to get a deeper dive on all the features being launched by product teams at Postman, please check out this month’s monthly wrap-up.

Until next time ✌️