I saw in a ticket that Newman is not related to the sunsetting of the Scratchpad feature. However, to run a Newman command you need to specify a collection ID - and collections are not available in the Lightweight Scratchpad.
Please can someone confirm if I am able to use an older version of Postman e.g. 10.13 or less, which still has the scratchpad, and integrate with Newman after September 15th? As the client is offline, and newman is offline this sounds possible, but if this is categorically untrue please can someone tell me what I can expect in September.
I appreciate the obvious workaround of upgrading to a free account, but at the moment I want a full understanding of all of my options before I commit to a solution.
If you âexportâ your collection you will still be able to run it through Newman. You would just use the path/filename.json instead of the collection ID.
eg:
newman run "C:\Users\James\Postman\myCollection.postman_collection.json"
Without signing into the cloud, you wonât be able to create collections in the Postman API Client. Scratch Pad will not be supported by Postman after September 15th, so there is no guarantee that things will work as they should over time. We recommend moving to the cloud to ensure the best possible experience.
Since collections wonât exist in the context of the lightweight client, there wonât be any concept of running them in Newman after September 15th.
Postman collections will still support running on Postman CLI and Newman, so you will be able to export the data to run these tests.
We recommend migrating to workspaces through our migration tool here. We understand that you might have questions about the migration process, so feel free to email us at migrate@postman.com.
You can choose to migrate when you sign up for Postman. You can also choose to migrate after signing up by selecting âkeep in Scratch Padâ on the prompt to migrate â itâs up to you. To migrate, use the migration tool, and select âMove data to workspaceâ on the migration prompt.
I still think that forcing you to sign in and sync data when all you want to is export the collection to your own code repository and run it locally using Newman and your existing ci\cli will in the long term, hurt the Postman client base.
Sounds like you wonât be adding any functionality to Newman as you are concentrating on your cloud hosted CLI. So this is another breaking decision for a lot of users. Same as the limits on the collection runner.
Itâs as if you are forcing users to go down the cloud hosted, CLI route through the back door (as that is probably where you make your revenue). On face value, this just appears to be decisions based on making money (which is fair enough as you are a company, but I just wish you would be open about it).
It will force some users that will not allow any of their data in the Postman cloud to look at alternatives.
The only way our Information Governance would allow us to use Postman Cloud in production would be an Enterprise license (for single sign on, etc), which is just completely over the top when we store and run stuff from our own repository.
I can keep most of the confidential stuff out of the cloud by using environment variables correctly, but it only takes one mistake to sync stuff you probably shouldnât.
Follow safe practices 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 value field, 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.
