Will earlier versions of Postman continue to use Scratchpad so I can carry on using Newman?

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.


Hi @debstaylor

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.


newman run "C:\Users\James\Postman\myCollection.postman_collection.json"

There is more info for running via Newman here:

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.

We are forced to use other tools and forbid usage of Postman, because it force to store the secrets in the postman cloud.

Hey @wingi :wave:

Sharing some good practices here:

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.
  • Learn more by reading our shared responsibility model.