scratchpad mode not visible in 10.14.2

[anoopaws-visy]

Is there an existing issue for this?

• [X] I have searched the tracker for existing similar issues and I know that duplicates will be closed

Describe the Issue

Hi, I'm running the following Postman version on my M1 Mac. This is a brand new install. Version 10.14.2 UI Version: 10.14.2-ui-230513-0653 Desktop Platform Version: 10.14.2 (10.14.2)

Issue: I'm not signed into Postman. I noticed that Postman doesn't display that I'm working locally in Scratch Pad mode (as described in https://learning.postman.com/docs/getting-started/using-scratch-pad/)

I'm unable to import local postman collections without signing up and logging in with a postman account.

Has the scratch pad mode been removed in the latest versions? Why do users need to sign in in order to import a local postman collection? This was not the case in previous versions.

Steps To Reproduce

As described above

Screenshots or Videos

No response

Operating System

macOS

Postman Version

10.14.2

Postman Platform

Postman App

User Account Type

Signed Out User

Additional Context?

No response

[giridharvc7]

We have deprecated the scratchpad with the release of V10.14, you can read more about it here.

We recommend using Workspaces for better organisation of your requests using Collections. Workspaces also give you a possibility to collaborate with your teammates. If you are not able to use or need help in moving to Postman workspaces drop us an email at migrate@postman.com

[anoopaws-visy]

Thanks for the reply. It's a shame that Postman have taken such a direction. The scratch pad mode allowed me to import and test postman collections without signing in. We're now being forced to sign in which is not ideal. I hope Postman reconsiders their direction. Thanks for the links to the blog. I had a look at the release notes and there was nothing in it to suggest that the scratch pad mode was being removed.

[zyrorl]

The problem isn't simply signing in for the option, it's that everything done in workspace mode is sync'ed to Postman's cloud, which can be a serious security issue for developers working on API's for customers that cannot sync those details to external systems.

[preethammavin]

@zyrorl we understand the concerns some customers might have, do write to us at migrate@postman.com so that we can understand your organization's needs better and help resolve them.

[zyrorl]

@zyrorl we understand the concerns some customers might have, do write to us at migrate@postman.com so that we can understand your organization's needs better and help resolve them.

I have done that, im awaiting responses:)

[feelchi1star]

We have deprecated the scratchpad with the release of V10.14, you can read more about it here.

We recommend using Workspaces for better organisation of your requests using Collections. Workspaces also give you a possibility to collaborate with your teammates. If you are not able to use or need help in moving to Postman workspaces drop us an email at migrate@postman.com

can we still use the workspace offline?

[pashau]

sorry to hear that you only support collections that are stored in your cloud now. I liked to work with postman but with our company data protection rules i'm not allowed to use it anymore.

[giridharvc7]

@feelchi1star You can send requests when you are offline. If you've requests that you have already accessed when online will be available to your workspace has gone offline.

[dbesade]

@zyrorl we understand the concerns some customers might have, do write to us at migrate@postman.com so that we can understand your organization's needs better and help resolve them.

I have done that, im awaiting responses:)

No you don't or you wouldn't have pulled this crap

[jonico]

I liked to work with postman but with our company data protection rules i'm not allowed to use it anymore.

@pashau: I am curious to learn more about your data protection rules. Postman is GDPR compliant and can also sign custom DPAs for enterprise customers. Furthermore, the actual API traffic is not going over our network, only the request templates with symbolic references to variables in payloads / arguments are saved there. Furthermore, current values of environment variables are never saved to our cloud either and we are working on supporting key vault integrations for sensitive values. Happy to chat more if interested.

[zyrorl]

I liked to work with postman but with our company data protection rules i'm not allowed to use it anymore.

@pashau: I am curious to learn more about your data protection rules. Postman is GDPR compliant and can also sign custom DPAs for enterprise customers. Furthermore, the actual API traffic is not going over our network, only the request templates with symbolic references to variables in payloads / arguments are saved there. Furthermore, current values of environment variables are never saved to our cloud either and we are working on supporting key vault integrations for sensitive values. Happy to chat more if interested.

Likewise this will be an issue for the company I work for. This isn't to do with GDPR compliance. This is to do with sending information about urls, requests, responses, etc. into your cloud. All our history of requests and responses get synced to your cloud.

The problem is also to do with the fact that when you do contracting work for customers, doing professional services work, you cannot expect that every customer you work with will be willing to sign DPA's with third party companies like Postman every time you engage with them. It's simply unrealistic.

I've raised this with your migrate@postman.com, and the response they give us is the same as yours, oh we're blah blah blah standards compliant, we're GDPR, we encrypt stuff. But completely un-addressing the real and serious concerns that any of this data is being synced to your cloud with NO option for a self-hosted cloud option, which would completely resolve the problem.

Even with per-seat licensing, on a self-hosted enterprise plan, this could be done, and we could avoid this entire shamozzle of removing scratch pad, and giving us a cut down, quite frankly featureless "offline" tool, that doesn't even import postman collections, which is quite frankly the hallmark of your product - the ability to share collections of requests so that developers and testers can use for testing entire suites of APIs.

[jonico]

@zyrorl: I x-linked your feedback with our internal feedback system.

This is to do with sending information about urls, requests, responses, etc. into your cloud. All our history of requests and responses get synced to your cloud.

Postman only stores the request template / data, that is, the request URL and payload with symbolic references to the used environmental variables as part of its history data. It does not save the responses (unless you explicitly configure this behavior in your workspace). Responses of manual /CLI collection runs or monitors are never saved. We are currently working on a feature to make it possible to disable the history service altogether or to only enable it in certain workspaces.

In the example above you can see that the environmental variable shows up in the history service, but does not reveal the value it had during the actual call. You can also see that manually entered (literal values like Volvo or Lego) have been preserved, but any symbolic references (like owner) stayed symbolic in the request URL and that the response is not saved.

But completely un-addressing the real and serious concerns that any of this data is being synced to your cloud with NO option for a self-hosted cloud option, which would completely resolve the problem.

We do not provide a self-hosted cloud option yet, but I added you to the requestors for such a solution, would you have any particular cloud in mind? Just to re-iterate, we do not save any current values (see screenshot 👇 ) of environment variables or any actual values of environmental variables used as part of requests to our cloud, nor do we save responses unless explicitly configured.

In our enterprise plans, we also provide the possibility to not sync secret environment variables (including initial value) at all to our cloud and are also working on a feature to turn off response template tracking in the history tab entirely - would that address your concerns until we offer a self-hosted cloud option?

[jnagle-nf]

I guess we shouldn't be surprised by this move. Whenever a vendor begins offering some kind of cloud service for a tool, it is inevitable the vendor will purge the ability to use the tool without the cloud service.

The only adequate solution is to hard fork the source code and either remove the cloud functionality, or make it agnostic. This is truly another emblematic example that only the Bazaar will look after your interests, and that the Cathedral will fail you.

[dbesade]

@zyrorl: I x-linked your feedback with our internal feedback system.

This is to do with sending information about urls, requests, responses, etc. into your cloud. All our history of requests and responses get synced to your cloud.

Postman only stores the request template / data, that is, the request URL and payload with symbolic references to the used environmental variables as part of its history data. It does not save the responses (unless you explicitly configure this behavior in your workspace). Responses of manual /CLI collection runs or monitors are never saved. We are currently working on a feature to make it possible to disable the history service altogether or to only enable it in certain workspaces.

In the example above you can see that the environmental variable shows up in the history service, but does not reveal the value it had during the actual call. You can also see that manually entered (literal values like Volvo or Lego) have been preserved, but any symbolic references (like owner) stayed symbolic in the request URL and that the response is not saved.

But completely un-addressing the real and serious concerns that any of this data is being synced to your cloud with NO option for a self-hosted cloud option, which would completely resolve the problem.

We do not provide a self-hosted cloud option yet, but I added you to the requestors for such a solution, would you have any particular cloud in mind? Just to re-iterate, we do not save any current values (see screenshot 👇 ) of environment variables or any actual values of environmental variables used as part of requests to our cloud, nor do we save responses unless explicitly configured.

In our enterprise plans, we also provide the possibility to not sync secret environment variables (including initial value) at all to our cloud and are also working on a feature to turn off response template tracking in the history tab entirely - would that address your concerns until we offer a self-hosted cloud option?

Lets try this another way since your eyes aren't communicating to your brain what customers are saying. We don't want this crap and after 20 years of Google and Facebook data mining "anonymous" cloud data to specifically target you and things you buy--- we don't trust you with our internal API calls. Nobody wants your cloud garbage. That getting through your firewall there buddy? Can I get an ack for my syn? You GETing whats being PUT down here?

[jonico]

we don't trust you with our internal API calls.

For the sake of posterity, your internal API calls are not traveling through Postman's cloud if you are using any Postman App or Desktop Agent or CI/CD integration:

Nobody wants your cloud garbage Can I get an ack for my syn?

I acknowledge that you do not like to use Postman's cloud-based platform. Postman has kept similar standards to Github for our cloud platform. Both GitHub.com and Postman are hosted in large US data centers and have similar certifications like SOC II, so as far as cloud usage and data privacy are concerned, it is a very similar situation. Both platforms have millions of happy community users as well as enterprises who trust them with their data. If you choose not to use Postman's cloud platform, everybody will respect your decision.

Again, for the sake of posterity, let me paste a diagram on what exactly is stored in our cloud and what is not:

[jnagle-nf]

I especially like @jonico's original edit of their above comment.

I acknowledge that you do not like to use Postman's cloud based platform, but you seem to be ok using GitHub.com at least for public conversations. Both GitHub.com and Postman are hosted in large US data centers and have similar certifications like SOC II, so as far as cloud usage and data privacy are concerned, it is a very similar situation. Both platforms have millions of happy community users as well as enterprises who trust them with their confidential data. If you are not among those, it is your own personal decision which everybody will accept.

Really mask-off here. Regardless of wording, they misdirect complaints about Postman's changes to insist that it's just like GitHub!

However it's far more honest to draw a comparison of how users want to use Postman to the freedom they have with Git.

You can run Git completely offline or under your own infrastructure. You may also choose to self-host GitLab.

Will we be able to have that control with Postman? Why did we have some of that control before?

[zyrorl]

@zyrorl: I x-linked your feedback with our internal feedback system.

I appreciate this thank you.

This is to do with sending information about urls, requests, responses, etc. into your cloud. All our history of requests and responses get synced to your cloud.

Postman only stores the request template / data, that is, the request URL and payload with symbolic references to the used environmental variables as part of its history data. It does not save the responses (unless you explicitly configure this behavior in your workspace). Responses of manual /CLI collection runs or monitors are never saved. We are currently working on a feature to make it possible to disable the history service altogether or to only enable it in certain workspaces.

In my experience, without explicitly turning this on, i can see that in my history i can see previous requests/responses, statuses etc. from past requests. I also cannot find a way to turn this off. Disabling the history service altogether would be a great step towards solving some of the data compliance issues.

In the example above you can see that the environmental variable shows up in the history service, but does not reveal the value it had during the actual call. You can also see that manually entered (literal values like Volvo or Lego) have been preserved, but any symbolic references (like owner) stayed symbolic in the request URL and that the response is not saved.

However this is kinda unusable. If we have to push all our request bodies into environment variables so they don't get synced, it'll make it much harder to manage collections.

But completely un-addressing the real and serious concerns that any of this data is being synced to your cloud with NO option for a self-hosted cloud option, which would completely resolve the problem.

We do not provide a self-hosted cloud option yet, but I added you to the requestors for such a solution, would you have any particular cloud in mind? Just to re-iterate, we do not save any current values (see screenshot 👇 ) of environment variables or any actual values of environmental variables used as part of requests to our cloud, nor do we save responses unless explicitly configured.

We would love a self-hosted AWS option. But any self-hosted (cloud or not) option would be also great. The point is that if we can give our customers confidence in being able to self-host all manner of request data, collections etc, within their own environments, without exposing sensitive information about either the inner-workings of APIs, or specific endpoints etc. Some of the customers we work with are in health, finance, banking, government agencies,and require stringent data storage policies, including the requirement for their data to reside within their own country and control. This cannot happen if the data is synced to postman's cloud.

In our enterprise plans, we also provide the possibility to not sync secret environment variables (including initial value) at all to our cloud and are also working on a feature to turn off response template tracking in the history tab entirely - would that address your concerns until we offer a self-hosted cloud option?

This will help, and may alleviate concerns for certain customers with less stringent requirements on data security, but for others it may still be insufficient.

[zyrorl]

I acknowledge that you do not like to use Postman's cloud-based platform. Postman has kept similar standards to Github for our cloud platform. Both GitHub.com and Postman are hosted in large US data centers and have similar certifications like SOC II, so as far as cloud usage and data privacy are concerned, it is a very similar situation. Both platforms have millions of happy community users as well as enterprises who trust them with their data. If you choose not to use Postman's cloud platform, everybody will respect your decision.

Comparing Github and postman are kinda a false equivalence. For a start Github Enterprise is an entirely self-hosted product (and there are cloud hosted options of course). This is available because Github realised that certain organisations simply cannot trust Github with their data (either for regulatory or legal compliance reasons - far beyond just mere certification). For example, would you expect that the NSA would store their source code on github.com? Of course you wouldn't.

Some of us work with organisations that have that level of data security requirements.

On top of that, many organisations also have specifically to go through entire security vetting programs in order to even use github.com where they have lesser requirements. This is an additional duplicate amount of work required to analyse and ensure that postman can provide the same level of assurance in data security, that many are not willing to carry out.

Again, for the sake of posterity, let me paste a diagram on what exactly is stored in our cloud and what is not:

This is useful thank you.

[jonico]

In my experience, without explicitly turning this on, i can see that in my history i can see previous requests/responses, statuses etc. from past requests. I also cannot find a way to turn this off.

Have you tried to log in from a different browser or the desktop app? The information you are seeing as part of the same session is mostly using data that is stored in your local browser only.

Disabling the history service altogether would be a great step towards solving some of the data compliance issues.

Agreed, this is a feature request we are working on at the moment (see diagram ☝️ ).

We would love a self-hosted AWS option. But any self-hosted (cloud or not) option would be also great.

Point taken and x-linked.

Comparing Github and postman are kinda a false equivalence.

My aim was to compare GitHub.com and Postman (as this discussion is going on on GitHub.com). I agree that going forward, a self-hosted or managed version of Postman would be very beneficial.

On top of that, many organisations also have specifically to go through entire security vetting programs in order to even use github.com where they have lesser requirements. This is an additional duplicate amount of work required to analyse and ensure that postman can provide the same level of assurance in data security, that many are not willing to carry out.

I very much understand that concern and can only say from 7 years+ working for GitHub and Postman that our solutions engineering teams do their very best to make this process as smooth as possible. This does not mean that we will be able to meet the security requirements of every single company out there (that's we we are lobbying for self-managed options as well), but in the majority of cases, we can demonstrate that our safety and data privacy practices meet the required standards.

[dbesade]

I think part of the frustration is we have self-hosted solutions today. For example, in Government we have completely isolated islands of control. There is no option for Cloud and even self hosted is difficult- so standalone is the name of the game.

[uRsIoNceNEdO]

Are those diagrams documented on the Postman site anywhere? I have been looking for that information, and unfortunately, a chat comment isn't sufficient backup.

[davidh2k]

Guess it's time to roll back to an older version then. Previous Version worked just fine for our use case. No need to be forced to use the cloud.

[MackW]

Simplest reason for me, is I cannot access the internet due to corporate policy on the development network - I use postman to test internal API's etc - and I don't have the ability to sign into postman. So a cloud solution is not viable - I guess I won't be upgrading any time soon (it's hard enough work getting the app onto the network as it is!)

[hell-racer]

I (and other team members on my project) will have to stop using Postman because of corporate policy. And downgrading is not an option too because of another poor decision - throwing that annoying "Upgrade available" screen at the user's face without ability to turn it off. I was using Postman for 5 years. So be it.

[erichuang-bh]

We need the scratchpad back.

login is the biggest issue.

[MeredithRodneyMcKay]

Just now i've started my Postman App again to check the current featureset for a new project and saw that the beloved Scratchpad mode is gone. I will not be able to continue to use Postman for our next project, nor my work in general.

Ever since i started using Postman i have advocated to all of my dev friends to also give it a shot. Most of them loved it. Especially because of being perfectly usable standalone, without the need for another login. Also you guys do realize that some customers (public sector e.g.) don't even allow internet connections, right?

Scratchpad: Install and you're good to go. Now: Install and... we need a Cloudservice? Go argue with your boss, then argue with the firewall team, then argue with the networking team, then argue with the security team, ... You know how those arguments usually go, right? Boss: Why another cloud service? Just find something that works standalone or is self hostable. Me: I really cannot argue against that.

To me it feels like this move has been made to squeeze money out of the Postman project. And i totally understand that. But there's ways to rake in money without destroying the very reasons why it's been popular in the first place. Offline licenses, self host server licenses, open source options, ... whatever.

As much as i have loved working with Postman... i guess it's time to find an alternative.

[blindstuff]

Yet another recent disappointment from Postman. Straying far from the decade of phenomenal track record.

[johnscott999]

I'm a lot more willing to fork over 20$, especially to a (formerly) favorite tool like Postman, than I am to have any data sent to a cloud that I can't control. This is also a step backward regarding usability and accessibility; unfortunately, API accessibility is the main thing that Postman brings to the table.

Postman was a revelation to me as a new developer. I didn't need to worry about where the data was going or set up a cloud server. It was so easy to use and to set up. What brought me to Postman wasn't a feature-rich workspace where I could share requests with teammates. Postman made novel APIs more accessible. Postman made it easy to try out endpoints and test how they handled different requests. This 'feature' is a significant step away from that.

I'm sad you are choosing to go down this road, but it is your prerogative as a company. It's mine, though, to choose to use another option.

[PaulAtST]

I have been using Postman since it was a chrome app only, looks like I am going to have to find a replacement. I understand business requirements change over time, but for many people and teams a cloud based monthly subscription is not a viable alternative. This also pretty much completely abandons the open source and educational market. It’s been shown time and time again in the tech world that tools used in open source and education eventually end up with the most developer mindshare. Postman will end up becoming an enterprise only tool if it stays on this path, which seems to be the complete opposite of what Postman started out trying to be.

[zyrorl]

Postman will end up becoming an enterprise only tool if it stays on this path, which seems to be the complete opposite of what Postman started out trying to be.

You've probably not read above, but even enterprises are going to have issues using this, due to data sovereignty reasons, customer requirements, government data ownership requirements etc. Unless they allow for private hosting of postman cloud services, most large enterprises won't be able to use it either.

[Monodytheone]

I have to say my company does not allow us to access the internet when coding. So good bye Postman.

[arlemi]

You can still use Postman offline, and without logging-in:

https://github.com/postmanlabs/postman-app-support/assets/5029719/c380d04c-17d3-4077-b3b3-a69b8c4a84e2

You can read more about the reasoning behind the sunsetting of scratchpad in this blog post: https://blog.postman.com/announcing-new-lightweight-postman-api-client/

[MackW]

You can still use Postman offline, and without logging-in:

offline-notloggedin.mov You can read more about the reasoning behind the sunsetting of scratchpad in this blog post: https://blog.postman.com/announcing-new-lightweight-postman-api-client/

Appreciate the can use the above offline, but may as well just a linux command line with Curl, using bash_history!

Does the lightweight client allow us to do Oauth, and every other type of auth in use that we have to cope with (Ie requests dependent on other requests) ? Does it allow us to group our requests into Collections - as we want to re-use requests, and no feckin clue when we last used that request, and all others associated with it? Can we use Variables (eg var jsonData = JSON.parse(responseBody); postman.setEnvironmentVariable("token", jsonData.access_token); )? I can't speak for anyone else bar myself, but I like postman for this, I don't care about GraphQL or the likes, as I don't use them, just plain old HTTP(S) GET/POSTS (mainly) requests and responses, Now I've got a very nice HTTPClass in C# that I could probably wrap into something similar, but since Postman already has that functionality - I will just stay with the version prior to the workspace sunsetting, because it works (simples). I honestly don't understand your reasoning for this other than a precursor for a moneygrab.

Regards, Mack

[SamTV12345]

You can still use Postman offline, and without logging-in:

offline-notloggedin.mov You can read more about the reasoning behind the sunsetting of scratchpad in this blog post: https://blog.postman.com/announcing-new-lightweight-postman-api-client/

The new "light" version is the biggest fun desktop app I have ever seen. With every request I do a new entry is added to the table. I can't import any requests anymore. Every functionality that is to share collections between developers is blasted away. I don't see a benefit in uploading collections now to the postman servers? I have one development PC and one open source development PC. If I change something in my postman collection I export that, add it to git and can sync with other colleagues. Why should I use an untrusted source like the postman servers to store my credentials? If you can name me a single benefit over this, please do so. I also noticed that Scratchpad has been wiped from your servers. If someone wants to download the old scratchpad because they like the ability not to upload everything to the cloud, they can't, because you removed every link to older versions.

This update could indeed be called Postman X or just X.

[lordcheeto]

Yeah, I doubt this will be approved for use in my organization. Good luck with the IPO.

[richardjanner]

According to the Postman blog '...For users currently using the Scratch Pad mode, it will continue working in deprecated mode until September 15, 2023.'

If I don't upgrade and just carry on using Scratch Pad mode, what will happen on September 15 2023? Is this really the drop dead date for using Scratch Pad mode? My organisation doesn't allow me to login to Postman and I really need to use collections, so it looks like I need to find an alternative tool, just trying to work out whether I HAVE to do this by middle of September.

[preethammavin]

We want to ensure Postman can continue to add value to our customers and blog goes into detail on why we deprecated the scratchpad. For all the questions on how we can serve you better whether it being your organization's constraints or any questions on security & compliance, do write to us at migrate@postman.com. This will help us answer your questions and concerns better.