It might already be intended by what is described here:
But here’s my ask:
In the “Manage Environments” screen, be able to set certain fields as “Prompt”, rather than entering a static value in the Value column. For fields set this way, when the user hits ‘Send’, show a prompt for the user to enter a value. This value is cached (though not displayed) for the duration of the session.
This is particularly useful for fields like Password that should not be stored
That’s an interesting idea. We have avoided adding prompts because one can really destroy the UX of testing through unwanted prompts. Also, this has other issues with respect to data types - sometimes values are not strings. Any other use cases that you can highlight?
Thanks Abhinav! Totally understand the reluctance to add prompts that could disrupt the flow when using Postman for testing. I think the UX risk here can be mitigated in a few ways:
In the Manage Environments screen, make it so that the user would have to explicitly set a given field to “Prompt” if they wanted to be prompted for the value at run time. In this way, you’re handing control to the user to make the decision on what kind of UX they want to have.
Don’t make the prompts modal. This way, if the user forgot to enter a promptable value, focus isn’t stolen. This also makes it trivial for you to have promptable fields that are mandatory and fields that are optional.
Couple of other use cases besides passwords that I think of:
Make it simpler for maintainers of API documentation to roll out Postman collections to developers/users in their organization. For instance, when I onboard a new QA tester today, I have to teach them how to manipulate the environments to (for instance) populate the JWT they get back after going through the authentication step of our API flow. With prompts, I could just roll out the collections and the QA tester would receive the prompt interactively.
Make it simpler to change data on each call to the API. For instance, if I was entering names into database via an API call, I could simply enter a new name into the prompt each time I hit the Run button.
Agreed. Thanks for the detailed comment. We have been thinking of a separate tab called “Variables” that comes in the Postman editor. That will let you edit all variable values in one place and prompt for unfilled values. I am thinking that there might be a way to combine that with the use cases that you mentioned.
The ability to provide credentials (or any sensitive data) at runtime, rather than storing them in Postman files would be a huge benefit to the tool. No one should be storing credentials in a file - even if they are not production credentials.
As a (possibly easier and less controversial) first step, how about permitting users to set variable fields (global, environment, collection etc.) as a password type, and not revealing their contents in plain text? Or, since there’s no place in the UI currently to set a param’s type, you could automagically do this if the name of the field is “password.”