It seems that postman now forces me to store my collections and environments in the cloud.
First they got deleted and after a forced sign in and import/recovery from local backup to be able to work, everything is now in the cloud.
Am I not able to use Postman with collections and environments without storing them on postmans servers?
10 Likes
Hey @rogerengstrom 
Welcome to the Postman community! 
You can Export all your data using the ⚙️ > Settings > Data option, this can be done from the Lightweight API Client. However, to Import this you would need to be signed in.
There is an FAQs section on the announcement blog which provides information about our security process and how we handle data.
This also provides a link to our Security and Trust Portal where you can request to download the latest SOC 2 report, SOC 3 report, CSA STAR and Security Features Report documents.
Here is the link to the Security and Trust FAQs which provides some more granular information.
In terms of the safe practices to follow with your data and credentials when using your Postman account:
- Be careful to avoid accidental data exposure when making a Postman element public, such as workspaces, collections, and environments.
- We strongly recommend you avoid storing sensitive data anywhere except within Postman environments. Storing variable values only in the
Current valuefield, will ensure that the data is never sync’d. - You should also use environment variables with a secret type to store sensitive data and credentials, including API keys and access tokens.
- Learn more by reading our shared responsibility model.
If you have any further questions, you can reach out to us on [email protected].
Please answer my question with a clear yes or no.
Can I use Postman with Collections and Environments without storing those on your servers?
2 Likes
In order to use Collections, Environments, etc. in Postman - You will need to sign in to an account.
You can use the lightweight API Client to send HTTP, WebSocket, gRPC, and GraphQL requests to test your APIs.
All of your work in the lightweight API Client is stored locally and isn’t synced online with Postman.
If you have created an account, you can Migrate all of the Scratchpad data to a Workspace by going to ⚙️ > Settings > Data and selecting the Migrate Data option.
Additionally, I was providing information relating to Exporting your data, some security based details which includes how all your data is stored, as well as good practices to follow when detailing with sensitive data with Postman.
Ok, so your answer is No.
That means I can’t use Collections and Environments locally anymore and one of my “good practices to follow” is not storing sensitive data on someone elses servers.
It feels a bit like you “hijacked” my collections environment data when my option to get it back was uploading it to your servers. I have really enjoyed Postman as an awesome app but I can’t share my environment data with you or anyone else so I’m leaving now.
11 Likes
You have the option to Export all of your data, as previously mentioned, it’s not being kept from you in anyway. You can Export this from the Lightweight API Client without signing in.
If you wanted to Import that data to continue your usage of Postman, you would be required to sign in.
Our recommendation is not to store any sensitive information within your Collections, this should be stored within your environments, using only the Current values so that it’s not sync’d anywhere.
2 Likes
While it’s great that there are ways to use postman without exposing these variables, relying on a convention (using Current Value to store these) is not a good design. I know lots of people who store these values in both the “initial value” and “current value” field. They’re not thinking about whether that data will go to Postman or not. I imagine lots of API keys, secrets, etc have been leaked to Postman since this update, and I share the OPs frustration with this.
7 Likes
Hey Alex ,
After signing up to a Free account, the data from Scratchpad isn’t automatically sync’d and available so nothing is leaked to Postman. You start with a blank slate.
Users will need to decide their next steps, either Export the data or Migrate the data into a Workspace. There is also nothing forcing users to sign up to a free account, we would absolutely love you to and make use of all the features of the Postman platform, the Postman CLI and the new vscode extension. A free account gives you the benefits of seamlessly syncing data across those different tools.
We have recommendations that users should be following to protect the sensitive data within their Workspaces, Collections, Requests, Environments etc. I mentioned that earlier in the thread and well as the links to our Security & Trust information.
We also have built in tools like the Secret Scanner, available for certain account types, which help prevent those different pieces of sensitive data from accidentally being exposed.
If users still don’t want to create an a free account, the Lightweight API Client will give them the ability to author and send requests to test their APIs, all while in a signed out state.
Thanks for the reply Danny,
I understand that Postman does not automatically upload user data to its server. My frustration exists because the Lightweight API Client is missing features that were there before the update, and the path for users to reclaim these features may cause them to take steps they don’t fully understand. Consider the following case
- User who uses Postman locally (without an account) updates Postman
- User notices that all of their collections are gone. In a state of panic they go to the Postman forum
- Postman support gives them step by step guides on how to get their collections back (by making an account and migrating data from scratchpad onto their new environment).
- Eager to get their collections back, the user migrates their data, unaware that the migration is not simply from the old scratchpad to their new account locally, but rather from their local machine to Postman’s servers.
Although secrets are a concern here, even the API endpoints that users hit (along with their data contracts) could also be considered by users to be private. It feels like this wasn’t considered at all before this update was rolled out.
Can you elaborate on what you mean by “There is also nothing forcing users to sign up to a free account”. Of course this is technically true. But isn’t it also true that you can no longer use collections without creating an account? If I have hundreds of collections that I’ve been using and one day they all disappear, isn’t there a very large pressure on me to sign up for an account? Or are you saying there is some way for users of the lightweight API client to still use collections? If this is the case, please let me know.
8 Likes
I have been using Postman to make authenticated requests to my server and I have historically been using the Environments to store sensitive data. @danny-dainton you’re telling me that with the update I have to rewrite all my collections to not use Environments?
Previously, I was able to do this because everything is local, and now you tell me about best practices on the Cloud. I don’t want the cloud. There cannot be a worse decision to make your users’ life harder.
2 Likes
You can still use secrets without having them stored on Postman’s servers. You’d have to do this by using the “Current Value” column in the environment. The issue here is more around the design of this recent update, which creates a strong incentive for non-account users to create an account and then migrate their data in order to get back the functionality they’ve become reliant on.
1 Like
@danny-dainton I don’t mean to be impatient, but is there any official response to my previous question and concerns? I would like to understand if Postman is moving in a direction that makes it unviable for use within my company.
3 Likes
The information contained in the links that have been provided on the thread, answer the questions you’re asking in term of what users can choose to do at this point.
You can either Export your data from the Lightweight API Client or Migrate your Scracthpad into a Workspace, after signing in to an account. At this point, you’re making the decision that’s right for you.
If the main concern is from a security standpoint, we have a large number of customers who had the same concerns. We have different types of plans to address those concerns which come with specific security features and safeguards in place.
For more extensive needs of Postman, our technical architects and solution engineers can assist you in understanding your problem and assisting you better. Please, reach out to [email protected] for further assistance.
You can still continue to use Environments to store your sensitive information, I would recommend that good practice. Storing these only in the Current Values will ensure that these are kept locally and never sync’d with Postman.
Relying on that people don’t make mistakes as the option for not leaking data is not sufficient.
Storing data on someone elses server is also not within the scope of “best practice”.
You decided for us that only the environments are sensitive data. Some of us don’t agree.
I’m sure you will do every thing in your power to keep our data secure but so did Microsoft, Facebook, Linkedin and others that have had breaches.
I’m really sorry to have to leave Postman since the functionality and gui have been awesome.
5 Likes
No. The links you’ve posted here do not address any of my concerns. Your security practices are not what this discussion is about. This is about the business practice of creating a panic (removing people’s collections) and then providing a solution (migrating data) that may cause users to accidentally expose confidential information. The fact that users have to do this process manually is not an excuse, and the insinuation that it is, comes across as a little insulting.
In good faith, I’ll reiterate it here again incase you accidentally missed it the first time.
Can you elaborate on what you mean by “There is also nothing forcing users to sign up to a free account”. Of course this is technically true. But isn’t it also true that you can no longer use collections without creating an account? If I have hundreds of collections that I’ve been using and one day they all disappear, isn’t there a very large pressure on me to sign up for an account? Or are you saying there is some way for users of the lightweight API client to still use collections? If this is the case, please let me know.
9 Likes
To understand your response correctly - in order to fit with your so called cloud best practices, I have to first export my collection, then open the exported JSON with VSCode and manually make changes to remove Initial Value from the environment, as well as all the hardcoded credentials I have for each request, then import it to the Cloud. This requires me to research on your export JSON format to make the right changes in the right place, absent of a UI that I’m used to.
Is that the correct understanding?
3 Likes
Thanks to this new feature I had to report a data breach at my company and the customer we are working for. I was not aware of the forced sign in automatically syncs all my data to servers in third countries.
I think our data protection team now will report it to the authorities.
5 Likes
Hey @knwf1977
Could you confirm that after signing in, another action was taken to either Export/Import the data or the Migrate data option was selected from the Settings?
When you sign in, from previously being on the Scratchpad, none of that data is automatically synced at the point.
Shared responsibility means that Postman has developed features and best practice but its down to the end user to actually use that best practice and the features they way they were designed. To actually go through the Learning Centre before jumping straight into development.
Please be aware, I might respond a lot to the help queries, but I don’t work for Postman and I’m not really seeing the data governance issues in relation to the Cloud that are being detailed in this thread.
The only issue that I would need some assurances on is around where the data is stored. It seems to indicate that its stored in AWS America, which might be an issue in relation to GDPR. Our internal governance dictates that this should be hosted in the EU and ideally in the UK data centres.
The initial vs current value issues is not really much different to forgetting to put in a Gitignore for your secrets when developing locally. This again refers to the personal responsibility.
At least Postman has now developed an extra feature to check initial values for well known key types.
If you really wanted to, you could pull all of your environments and collections via the Postman API and loop through all of the values, not just the well known ones. It won’t stop someone setting it wrong, but at least you can check periodically.
You can’t really expect Postman to develop features to protect you from everything you might do incorrectly, as that would just create bloatware and potentially make simple tasks much harder to achieve.
As far as I’m aware, the data that Postman store in the cloud is encrypted in transit and at rest.
Your collections are protected by API keys and there are audit controls for this aspect. Pretty sure that Postman staff don’t have access to your collections unless you share the API keys.
The Enterprise plan also has single sign on, 2FA and static IP support.
For most orgs, I suspect that you would need the Enterprise plan to keep your Information Governance teams happy. (Which may be an issue due to the cost).
Personally, I export the collections and environments and then run them from my code repository using our continuous integration platform (which is hosted, by Microsoft). Therefore the cost is a factor for us, as we don’t really need all of the other features at this point in time.
I’m guessing the main issue here is actually the sunsetting of the scratchpad which would allow you to store your secrets in your collections as initial values against best practice. The issue is really about migrating that data.
Postman have explained why they are sunsetting the scratch pad which is related to maintaining two sets of code for the online and offline versions.
It prevents rapid development of new features in relation to collections as it has to be developed and tested for the two different scenarios and the overhead that goes with that.
I’m not justifying that decision, but that is Postman’s justification and from my perspective, it sounds like a legit development concern.
The lightweight client will allow offline usage, but it is exactly that. A lightweight client for sending requests. It won’t allow the running of collections.
This is a commercial decision and there is nothing anyone on this forum can do about this. Perhaps the communication could have been a bit better though.
2 Likes