Actually you can just run an older version…
It’s amazing what you can do with a windows hosts file. If you have the access to edit it on your system which for small scale and hobby users you probably will.
0.0.0.0 dl.pstmn.io
0.0.0.0 sync-v3.getpostman.com
0.0.0.0 getpostman.com
I am still unclear. If I’m on an older version of Postman and I have blocked the updates for Postman, will ScratchPad continue to work after September 15? Can someone from Postman confirm this will impact all versions of Postman or just newer versions?
I for one and happy to see this Postman change…
…because I want to see everyone here learn to love open source tooling.
Open API (Swagger), or “Insomnia” and “RestFox” (both work the way “old Postman” used to work).
The data-compliance issues here are going to force a migration off Postman. You guys found the line. Cheers.
I did used to love the “old Postman” but this new Postman has so many “closed” UI bugs, data corruption issues. It is clear someone values their bonus check (getting more Postman accounts) over longer-term community happiness. I bet the metrics look great.
[…] will ScratchPad continue to work after September 15?
Scratch Pad will not be supported by Postman after it reaches end of life, so there is no guarantee that things will work as they should over time.
Actually you can just run an older version…
Yeah I realized I could do just that. Using last v7 release at this point since it was the last release before Scratch Pad. I really can’t recall anything they added since Scratch Pad came out that was of any benefit for how my team uses Postman.
I still have to look into what version of newman to target with my CI/CD process to make sure it stays stable with the Postman v2.1 collection format that v7 can export. Thankfully whatever version of newman I go with it should never be able to be taken off npm.
We have that at least. You have any suggestions on best Postman / newman version combo that won’t nag about Scratch Pad going away and that works well with newman etc?
Think about it. If you have Postman installed and blocked it from updating, as long as it’s an old enough version to not have a kill switch for September 15th, you should be fine indefinitely as long as it continues to work with your OS. Personally, I have a copy of a much older release saved from before Scratch Pad was even a thing so I don’t loose access to it and so far so good.
This is a deal breaker; my organisation WILL NOT allow collections (which can contain all sorts of credentials) to be stored in some external company’s cloud service (offshore at that, so not even subject to local laws). Scratchpad was the only solution we had to this, and now it’s deprecated.
This has only come to light recently because we tried installing the latest version for a consultant. Luckily our local versions were blocked from updates for the same reason the consultant couldn’t log in to create an account, so we still have access to scratchpad.
Let’s not forget to call out Postman’s lightweight API client (scratchpad’s replacement) - which is beyond useless when you have a collection of hundreds of APIs to test.
Performance issues aside, anyone with an ounce of security sense will see the stupidity in this decision as it just screams DATA BREACH. I don’t know if any of you have seen articles calling out hackers scanning publicly exposed collections for endpoint credentials (Hackers Scour Exposed Postman Instances For Credentials and API Secrets | Threat Intelligence | CloudSEK), and you can be sure that POSTMAN have put a target on their backs encouraging hackers to gain access to their servers for everything else. It is only a matter of time now.
Well done POSTMAN for officially killing your product, now I have to find an alternative solution for about 20 employees and deal with the learning curve.
Couldn’t agree more - this just screams data breach.
I also want to call out the sneaky way in which Postman rolled out this change to their product, which impacts any installation that doesn’t block access to their download servers. You can disable “major” updates in settings, however minor patches cannot be disabled. How is the deprecation of major functionality rendering the product useless for certain organisations considered a “minor” update??
That’s pretty disrespectful to the community, it is so blatantly obvious that Postman knew this would be an issue for customers.
Not defending Postman here, but you shouldn’t have any credentials in your collections.
They should be in your environment files and in particular, they should be in the current value, which doesn’t get synced to the cloud or if you export to a .json file.
You then store your credentials somewhere else. (Not in your code repository). Ideally in something like a key vault.
When testing locally, you will have to copy and paste the credentials.
When running though a CI tool, you send the credentials in the CLI that calls Newman.
When I tried using the online workspaces I did find that the credentials in my environment were sometimes synced to the cloud 
Initial values get synched, but current values do not.
It should confirm this when you hover over the tooltip when you select an environment.
The current values are also not included if you export the environment, just in case you store it in your code repository.
Based on the tool, we usually do a risk assessment during software assessment and that usually covers the types of questions you are posing.
I’m not sure its a tools job to save you from yourself? As that usually involves creating a lot of overhead in developing the tool but I also know those risk adverse organisations exist.
As saving a collection in public can be a legitimate activity, how and who would determine if its been saved “inadvertently”?
On a side note, it shouldn’t be that hard to develop a collection that retrieves all of your collections\environments for a team and then loops through them checking initial values for someone to review.
Unfourtunately some companies’ policy doesn’t allow to store data in cloud, so this basically means that in this case we are not able to use Postman any more, right?
Hey @renathy 
Welcome to the Postman Community! 
Postman can still be used without signing in or creating an account, the Lightweight Postman API Client enables you to send HTTP, WebSocket, gRPC, and GraphQL requests to test your APIs.
It stores data locally and isn’t synced online with Postman.
The issue is that is one request at a time and the collections we have cannot be saved by exporting them or re-importing them. So ad hoc requests great, but some of us use Newman in our pipelines with the need to export the collections to run.
@svitlanna are you using the lightweight version, without signing in ? How are you making sure your files are getting uploaded to Postman cloud ?
I believe @svitlanna created a free account and migrated the data from Scratchpad, into a Workspace, to continue working with their Collections and Environments.
Hey folks ,
To address the questions that have been raised in this topic, we have created an FAQ section on the blog post.
This contains information about how Postman protects your data and it provides a link to our Security & Trust Portal, where you will find additional details about our product security, privacy, compliance, and reliability information.
If you’re still prevented from using Postman in a signed in state by your company’s security policies, you can reach out to our technical architects and solution engineers at [email protected] for further assistance.
Also, the FAQ section provides details about how you can migrate your data from Scratchpad, into a Workspace, after signing up to an account.
For the folks who would still like to use Postman in a non signed in state, you can do so using the Lightweight API Client to send HTTP, WebSocket, gRPC, and GraphQL requests, to test your APIs.