Announcing an easier variable experience 🎉

With October kicking off the thrilling final stretch of the year, we’re excited to add to the buzz with some news!

I must be a new name to most of you, so I’ll start with me. I’m Shobhit from the API Client team, the team that works on the request-sending experience on Postman. This post is about some exciting stuff we shipped last week that I feel is relevant to all of you and can make testing APIs with dynamic values oh so much easier! Easy guess from the title– I’m gonna talk about the new variable experience.

Working with variables is an old fable in Postman, riddled with complexities and sometimes anticlimactic ends. One must be familiar with the nitty-gritty like scopes (Collection, Environment, Global and more) and their distinctions to use a variable or even update its value. Plus, having a variable in a scope doesn’t always mean it’s ready to be used. It could be empty when someone tries to send a request, and it’s hard to scout for these empty variables and deal with them. All that goes away starting last week with our newest update– V11.14! Working with variables is as simple as following the yellow brick road (Wizard of Oz, anyone?).

Hover and set variable values on the go

No more visiting collections or environments to edit variables. Just hover on a variable, view its value, and change it in the pop-over. This updates the value locally—in Postman terms, it updates the current values of the variables. So you can keep experimenting without worrying about the values being shared.

edit-value

Never miss an empty variable

Postman now highlights the empty variables that need your attention with a popping red paint job. So, you can focus on the important bits required for a green 200 OK.

empty-variable

Use variables without a scope

Not all variables belong in a scope. Variables can be used as placeholders to ask for case-specific values. These values could be necessary to complete a request but may not be intended to be reused. Plus, the idea of adding a variable to a scope to be able to use it adds rigidity to how request parameters can be configured.

With this release, we’re shifting to a more flexible system where adding variables to a scope can be optional and more intent-driven. You can create and use variables without a scope and share them with the request. This serves as a prompt for the consumers to enter the values before hitting ‘Send’. The values of these variables are stored locally and are flushed out as soon as you close the request tab.

unscoped-variable

All your variables in one place

Variables could be scattered all around the request interface. While you’re testing a request for different scenarios, the last thing you would want to do is go to each variable and change the value individually. That’s why we’re shipping a new variables pane that acts as a console for interacting with all the variables, a.k.a. all the moving parts of the request from a single interface. Set your values, hit send, change the values, and hit send again. This pane also gives you access to all the variables available to you, so you can pick the ones necessary for a request configuration without leaving the request.

Additionally, the trigger to open the variables pane gets highlighted with a red error icon to draw attention to empty variables in the request. So you always send requests with confidence.

variables-pane

Try the new variable experience today!

These improvements have been released as part of Postman V11.14, and we can’t wait for you to try them out! Update your Postman app or download Postman (if you haven’t already) to start working with the updated variable interface.

We would love to hear your feedback on how we can improve this experience further. Do keep us posted :crossed_fingers:

5 Likes

Looks interesting.

My first question is around accessibility. Are the colours for empty and active variables configurable. Red is one of the colours that colour blind users may struggle with.

@michaelderekjones That’s a valid point. We were going for a border-based distinction (dotted border for empty variables and subtle continuous border for filled variables). But I agree; the difference can be a bit more prominent. I’m noting this down as a required improvement.
image

2 Likes