Announcing an easier variable experience 🎉

[postmankatikia (Shobhit Katikia)]

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.

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.

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.

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.

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

[michaelderekjones (Mike Jones)]

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.

[postmankatikia (Shobhit Katikia)]

@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.

[cnsstsod (Sten Söderberg)]

Great to see improvements to variables. We are working with about 4 different API’s that needs to be tested towards 5 Environments (Production, Testing, Development, Upgrade and Staging). Working with variables makes it super easy to switch between the environments without rewriting the tests.

So a few suggestions about improvements based on this experience;

1. It would be great to copy one variable from one environment to others. Today if we add a variable called Path to one environment, we need to add it to the other four and it takes quite much time. Would be great just to be able to copy it.
2. Would be great to have a kind of PivotTable showing Environments as Columns and then variables as Rows. Then it’s very easy to find if a variable is missing in an environment or if it’s incorrect spelled in one or two environments.
4. Would be great if variables could be trimmed for blank in the end. Misstakes happens, for example the variabel Path is totally different from Path where do don’t have a bland in the end . It’s quite hard to spot them in the variabel list, so just beeing able to trim trailing blanks would be great.
5. COMMENTS, COMMENTS, DESCRIPTIONS, DESCRIPTIONS … We only have about 150 variables in the list, but sooner or later we will end up with 400-500 variables. Not beeing able to comment them makes it really hard for the developer community to know the purpose of the variable. So having more metadata attached to variables would be so very useful.

[malpstibo (malp)]

After this change, updating environment variables in the environment tab no longer seems to work. Even though the update is saved on the environment panel, subsequent calls still use the old value.
edit: by the environment tab/panel, I mean the one found in on the left hand side below “Collections”. The one on the top right seems to work.
If I set the value using the new hover method, it works fine.

[danny-dainton]

Hey @malpstibo

Are you able to share a short recording of the behaviour, please?

It would help us to better understand the issue you’re facing.

[postmankatikia (Shobhit Katikia)]

@cnsstsod Thanks a lot for the amazing suggestions! Some of them are already on our list of updates to be done to ‘Environments’. Your comment just strengthens our assumptions. Thank you again

[cruxto (Paul C)]

The update for variables is a welcome improvement

One suggestion I would like to make is, would it be possible to add a variable filter to the new variables area the same as the one in Collection variables for example? So when you have a lot of variables you can find them quickly without scrolling through the whole list.

[postmankatikia (Shobhit Katikia)]

@cruxto That’s a great suggestion!

[celestina01 (Celestina Prochilo)]

Is it possible to turn off the red error warning on the environments icon for empty variables? I get a warning for local variables set in my pre-request scripts.

[postmankatikia (Shobhit Katikia)]

@celestina01 Thank you for the feedback and I agree! It can be annoying for variables being set via scripts. I’m noting this down as an improvement to be done.

[celestina01 (Celestina Prochilo)]

Thanks! Another reason someone might want to turn off the warnings - sometimes there is a need for a variable in one environment but not another.