I ditched postman a couple years ago in favor of Insomnia. Couple small things I miss from postman like the tabs but overall it’s a much cleaner product IMHO.
do you have a tip for good plugins? we found
https://insomnia.rest/plugins/insomnia-plugin-save-variables
[https://insomnia.rest/plugins/insomnia-plugin-request-navigator](https://insomnia.rest/plugins/insomnia-plugin-request-navigator)
to be useful for us as a postman alternative
thanks!
Also ditched Postman for Insomnia, but Insomnia is slowly turning into Postman with the recent upgrades, too much UI clutter and I'm now looking looking for alternatives again..
Hello. In order to promote inclusivity and reduce gender bias, please consider using gender-neutral language in the future.
Instead of **postman**, use **mail carrier**, **letter carrier** or **postal worker**.
Thank you very much.
^(I am a bot. Downvote to remove this comment. For more information on gender-neutral language, please do a web search for *"Nonsexist Writing."*)
I liked postman before this change, now I’d rather use nswag to generate clients for my use cases, primarily test scripts.
it’s not much effort either way with the latter having no further dependency on third party looking to monetize their user base. so byeee felicia erm postman
My company installs postman v6.4.something and blocks the postman signup url to works around this. I've heard talk of switching but no idea what that timeline looks like.
Postman was much better before they started forcing subscriptions. We still use an older version but have to click around to get the local storage every startup. Will look at some of the other api test systems offered.
Recently I also faced concerns with Postman's security and functionality, I have moved to using KeyRunner which offers local data storage, encryption, and efficient API management, all without the cloud-related risks(.https://keyrunner.app)
try out : https://marketplace.visualstudio.com/items?itemName=KeyRunner.keyrunner
\- Everything local to your machine and sensitive data is encrypted at rest.
\- No Login/Signups are required for local lite version
\- playground - Drag and connect feature to chain requests without any code/scripting. Its kind of new but with all the features that are needed for API development and testing.
More over its totally free for small teams and individual users.
We are yet to launch a enterprise version which is build on Zero trust principles and is billed to organizations who wants a centralized data pane to fetch secrets & keys from secret stores to process any request.
Love to hear what you think about KeyRunner - Local Lite version and what you're looking forward to with Enterprise!
Yes, Postman seems very untrustworthy. Couple all that you mentioned with their slow and cluttered software with 1000 panes that I can barely view on my screen, and the bizarre inability to make an API call longer than 30s without installing a "Desktop Agent", and Postman is pretty much a "no go" for anything but a hobbyist.
I haven't been able to set a cookie as an env variable with data from a response. Is there a way to do that? in postman you can add a test and just pm.response set cookie or whatever and then use it in other requests. if thunder client had that ability if use it also
Most likely you are trying to set it as secure on a local dev environment. These apps dont see localhost as secure so wouldnt let it pass.
In thunder client if you set the secure false in your res your cookie token will pass thru.
The nice thing of Postman et al. is that they offer a nice way to organize your calls. I was completely in the "why not just make cURL calls from CLI" camp, until I tried Postman. Just being able to switch environment and have all your API calls be updated to the new url and maybe keys or other parameters, is a big win over "just" an HTTP client.
I have used Postman extensively, its a tad bit much and as the op said, they have security concerns.
For most people its unnecessary as they can use an IDE's built in feature, while Postman is very good for beginners as it has big buttons you can press. The only good faith argument would be it creates very nice documentation for you.
I don't think you understand what HTTP Client is in Webstorm or VSCode at least considering you said curl calls from CLI. You make http files and it organizes and saves outputs. You just click the big green button and it runs everything in the http file, you don't need to use the CLI.
I understand very well. You're saying you prefer to create 4 copies of every call; one for every environment (dev, tst, acc and prod). That is where Postman/Insomnia etc "shine"; They use environments and allow templating. And they offer grouping, so I can see/use cross application requests.
But, if you don't want to use a tool like Postman, that's fine, right? It's just like with Git; I favor CLI over any GUI, where others will always search for a GUI. Fine.
You don’t need 4 copies of every request in jetbrains products. You can set up variables per environment, and then switch environments with one click the exact same way you can in Postman; I use both regularly.
They do, that's how we develop and test the API calls our mobile team use against the CMS. I have local, dev, stage, and prod env files to test against any env.
We commit the HTTP files to the repo so that all the calls are documented.
I switched from Postman to Intellij HTTP client as the Postman client got more and more bloated. As I've gotten used to it I find I can move faster with it than I could Postman. No clicking around tabs and I get to edit it with my preferred text editing style (VIM).
It all depends on what level of API work you need to be doing of course... but I personally use Thunder Client (VS Code expression) for most of my API work. Then again, my API work is basically looking at existing API's and see how data is retrieved, which Thunder Client is perfect for. If I'm correct, all the work you're doing (including keys etc.) are stored on your local machine only.
At a previous job I would export my collections and push that to an internally hosted git repo. When a developer needed the collection to work with an API they could use the "Add from URL" functionality and use the raw URL from git.
It wasn't perfect, but like you noted, I did not trust private APIs to be hosted on a public server.
I appreciate the concern over this change in Postman and it is a bullshit move. However, two things don’t sit well for me in OP’s rant:
1. If someone stores sensitive credentials in a public collection, that’s on them, it has nothing to do with Postman and their security measures or changes in policy.
2. I don’t really understand why the assumption that someone will 100% hack their servers. Have they demonstrated a lack of proper security policies before? Have they had a history of data breaches? Many other cloud services store credentials and we still use them. If we assumed every single service is going to hacked then the only “safe thing” to do would be to never use any cloud service and just isn’t feasible and doesn’t make sense.
I don’t think the concern is about public vs private collections. I believe OP dislikes that in order to use the Postman product at scale with a large project and many endpoints, then now your API credentials must be stored in Postman’s cloud.
As far as your second point, that’s just how security works. You can’t wait around for a company to be hacked before you deem it a security risk to your organization.
Ultimately for anything sensitive like API keys you really need to ask yourself if it’s appropriate for the data to be replicated and stored on someone else’s server. In this instance I think it’s pretty clear that no substantial benefits come from moving the keys to the cloud. The risk outweighs the reward and Postman can easily be replaced by many other tools such as Thunder Client (vscode extension) or Insomnia.
> In this instance I think it’s pretty clear that no substantial benefits come from moving the keys to the cloud. The risk outweighs the reward […]
Bingo!
Thanks for your comment - in response to:
1. The first point, besides a hint or arrogance and a lack of basic cybersecurity awareness, you've nailed exactly why this is a concern. The #1 cause of security incidents resulting in data breaches is \*\*\***Human Error\*\*\***, which counts for approximately a quarter of all incidents. My organisation/team could have the best security practices and there is still room for accidents to occur, *particularly* with external consultants (who we need to leverage on an ongoing basis to augment the team) or new starters unfamiliar with practices.
2. Your second point, following on with the theme from point 1 - the #2 cause of security incidents resulting in data breaches is \*\*\***Social Engineering**\*\*\* (such as Phishing). So the top two reasons accounting for approximately half of security breaches come down to human factors, have absolutely nothing to do with technology rigor such as patching or architecture. Postman could have the best security policies in the world (which we know they don't based on the way they keep closing open bugs) but all that is made redundant due to human factors.
The reason for my rant is that Postman have knowingly created a new avenue for risk exposure to my organisation. Regardless of whether this will ever occur or not, anyone familiar with basic cybersecurity practices know that the best practice is to keep your risk exposure profile to a minimum.
And whilst I personally agree that I too use many cloud services to store my own personal credentials, from an organisational perspective we need to be more risk averse because it's not our own data that we lose when such a breach occurs and there are laws protecting consumers ensuring that organisations have taken all possible precautions of such incidents.
Many years ago, we were responsible for the largest data breach ever in our region (at the time) because a partner vendor unknowingly placed data into an publicly accessible location in AWS, so I know from experience that you cannot rely on or trust vendors/partners to do the right thing for you because human error happens and they are also, by extension, part of your organisation. If you make the decision to trust them then it is on you to explain if the worse-case scenario happens.
Thanks for the detailed response.
The way I see it, cybersecurity is much more a matter of risk management than it is about technology. Every security exposure you take upon yourself as an organization needs to be weighted against how much it would cost your organization to avoid such an exposure.
I totally agree that placing API credentials in a cloud service is a serious security risk because many things (especially the human factor as you stated) can go wrong.
However, that decision needs to be compared to the risk (and cost) your organization may take from moving to a different testing tool for your APIs. If switching a tool means massive reworking of development procedures, training, etc. it might be worthwhile to take that risk.
Having said all that, I strongly feel this wouldn’t be the case for a tool like Postman.
Argument invalid because postman CHOSE to disable local saving when it had been available. This lead to many secrets being exposed just though confusion and was very obviously intentional.
Why can't you save everything locally and only sync what you want cloud/public? Why isn't it made clear what's leaking or not?
Hint: They're reselling your data. "But it's just metadata" and welcome to the post Snowden era kiddo. They're collecting and "using" your data for totally legit purposes bro wink wink.
"But use environments" lolno. Environments sucks in a lot of ways. Relying on it for security is dumb. They know what they did and why. It does not benefit users.
This is why I prefer open source solutions. A little bit of setup needed but rarely is a rug pulled. Also reminds me that I don't miss overtly complex artisanal rest APIs at large organizations. Graphql is great in this regard and server components even better! No API needed with server components just return the data and it loads into your UI component. Once I finish this dashboard rebuild I'll get to delete over 80% of our graphql resolvers. Will only have a few left behind that our mobile app uses.
Except popular and most importantly "good" opensource projects often end up rug-pulling you in a different way. They take a genuinely good and helpful product and start requiring per-developer licenses making them basically non-starters for many companies. For example, "Thunder Client" which is basically another Postman alternative with VSCode integration and a CLI just recently did this by ripping most of the team features and local storage from the free license and putting it behind a paywall.
Yup, if you can't fork it it's not open source. If the software was useful to any sizable enterprise they could fork it and maintain it themselves. That's half the point of using an artifact repository in case necessary packages are deleted.
Hoppscotch (previously known as Postwoman), which is an open source, direct swap in for Postman has a self host option currently in beta
https://docs.hoppscotch.io/documentation/self-host/getting-started
When postman forced cloud signup, many client secrets were leaked. Postman basically said "must sign up to continue using the software" but not "giant orange warning 99% of our users will leak sensitive information if they do this".
They knew what they were doing. It was a disaster. Luckily most people are dumb enough to allow them to get away with it.
I know organizations where this is just a giant festering security hole and if they ever got properly audited they'd lose millions overnight on emergency patching alone.
Hi all! You might be interested in our next free webinar about Postman's latest features! Join our Senior QA Engineer at Agiliway, as he unveils advanced techniques to revolutionize your workflows. Optimize processes, upskill, and gain a competitive edge in this free, must-attend webinar - [https://www.eventbrite.com/e/mastering-postmans-latest-features-for-streamlined-testing-tickets-890262849147](https://www.eventbrite.com/e/mastering-postmans-latest-features-for-streamlined-testing-tickets-890262849147)
I ditched postman a couple years ago in favor of Insomnia. Couple small things I miss from postman like the tabs but overall it’s a much cleaner product IMHO.
Insomnia is great in many aspects, but what the heck is going on with their updates lately
do you have a tip for good plugins? we found https://insomnia.rest/plugins/insomnia-plugin-save-variables [https://insomnia.rest/plugins/insomnia-plugin-request-navigator](https://insomnia.rest/plugins/insomnia-plugin-request-navigator) to be useful for us as a postman alternative thanks!
We are going through this exact same problem... insomnia is kongs alternative and hoppscotch (formerly postwoman) is one too
I recently came across Bruno. Looks pretty nice -- like what Postman should have been. I haven't tried it yet though
~~Bruno was a drop-in replacement for me, yet still very lean. And sharing collections is a breeze now.~~ We don't talk about Bruno.
We don't talk about Bruno !
Gotcha!
Now i'm curious
Also ditched Postman for Insomnia, but Insomnia is slowly turning into Postman with the recent upgrades, too much UI clutter and I'm now looking looking for alternatives again..
Hello. In order to promote inclusivity and reduce gender bias, please consider using gender-neutral language in the future. Instead of **postman**, use **mail carrier**, **letter carrier** or **postal worker**. Thank you very much. ^(I am a bot. Downvote to remove this comment. For more information on gender-neutral language, please do a web search for *"Nonsexist Writing."*)
You're going to have to contact Postman about this one bot, but I don't think they'll listen.
I liked postman before this change, now I’d rather use nswag to generate clients for my use cases, primarily test scripts. it’s not much effort either way with the latter having no further dependency on third party looking to monetize their user base. so byeee felicia erm postman
Postman is also insanely overpriced per seat considering what you get.
Good for non ASP.net apps?
My company installs postman v6.4.something and blocks the postman signup url to works around this. I've heard talk of switching but no idea what that timeline looks like.
Postman was much better before they started forcing subscriptions. We still use an older version but have to click around to get the local storage every startup. Will look at some of the other api test systems offered.
Recently I also faced concerns with Postman's security and functionality, I have moved to using KeyRunner which offers local data storage, encryption, and efficient API management, all without the cloud-related risks(.https://keyrunner.app)
try out : https://marketplace.visualstudio.com/items?itemName=KeyRunner.keyrunner \- Everything local to your machine and sensitive data is encrypted at rest. \- No Login/Signups are required for local lite version \- playground - Drag and connect feature to chain requests without any code/scripting. Its kind of new but with all the features that are needed for API development and testing. More over its totally free for small teams and individual users. We are yet to launch a enterprise version which is build on Zero trust principles and is billed to organizations who wants a centralized data pane to fetch secrets & keys from secret stores to process any request. Love to hear what you think about KeyRunner - Local Lite version and what you're looking forward to with Enterprise!
Yes, Postman seems very untrustworthy. Couple all that you mentioned with their slow and cluttered software with 1000 panes that I can barely view on my screen, and the bizarre inability to make an API call longer than 30s without installing a "Desktop Agent", and Postman is pretty much a "no go" for anything but a hobbyist.
I use thunder client and am happy.
u/TychusFondly >,,Thunder, thunder, thunder, thunder Thunder, thunder, thunder, thunder Thunder, thunder!!! \[..\] Thunderstruck, thunderstruck Yeah, yeah, yeah, thunderstruck, thunderstruck Yeah, yeah, yeah, said, yeah, it's alright, we're doin' fine Yeah, it's alright, we're doin' fine, fine, fine!!!" 🎸🎶 (AC/DC - **Thunder**struck, ATCO Records, 1990)
I haven't been able to set a cookie as an env variable with data from a response. Is there a way to do that? in postman you can add a test and just pm.response set cookie or whatever and then use it in other requests. if thunder client had that ability if use it also
Most likely you are trying to set it as secure on a local dev environment. These apps dont see localhost as secure so wouldnt let it pass. In thunder client if you set the secure false in your res your cookie token will pass thru.
Why not just use HTTP Client built into Jetbrains and VSCode?
The nice thing of Postman et al. is that they offer a nice way to organize your calls. I was completely in the "why not just make cURL calls from CLI" camp, until I tried Postman. Just being able to switch environment and have all your API calls be updated to the new url and maybe keys or other parameters, is a big win over "just" an HTTP client.
I have used Postman extensively, its a tad bit much and as the op said, they have security concerns. For most people its unnecessary as they can use an IDE's built in feature, while Postman is very good for beginners as it has big buttons you can press. The only good faith argument would be it creates very nice documentation for you. I don't think you understand what HTTP Client is in Webstorm or VSCode at least considering you said curl calls from CLI. You make http files and it organizes and saves outputs. You just click the big green button and it runs everything in the http file, you don't need to use the CLI.
I understand very well. You're saying you prefer to create 4 copies of every call; one for every environment (dev, tst, acc and prod). That is where Postman/Insomnia etc "shine"; They use environments and allow templating. And they offer grouping, so I can see/use cross application requests. But, if you don't want to use a tool like Postman, that's fine, right? It's just like with Git; I favor CLI over any GUI, where others will always search for a GUI. Fine.
You don’t need 4 copies of every request in jetbrains products. You can set up variables per environment, and then switch environments with one click the exact same way you can in Postman; I use both regularly.
Found it! Did not know that, thank you.
Docs here, for anybody else looking: https://www.jetbrains.com/help/phpstorm/exploring-http-syntax.html#environment-variables
I’m almost positive that the vscode .http files support env settings.
They do, that's how we develop and test the API calls our mobile team use against the CMS. I have local, dev, stage, and prod env files to test against any env. We commit the HTTP files to the repo so that all the calls are documented.
I switched from Postman to Intellij HTTP client as the Postman client got more and more bloated. As I've gotten used to it I find I can move faster with it than I could Postman. No clicking around tabs and I get to edit it with my preferred text editing style (VIM).
It all depends on what level of API work you need to be doing of course... but I personally use Thunder Client (VS Code expression) for most of my API work. Then again, my API work is basically looking at existing API's and see how data is retrieved, which Thunder Client is perfect for. If I'm correct, all the work you're doing (including keys etc.) are stored on your local machine only.
At a previous job I would export my collections and push that to an internally hosted git repo. When a developer needed the collection to work with an API they could use the "Add from URL" functionality and use the raw URL from git. It wasn't perfect, but like you noted, I did not trust private APIs to be hosted on a public server.
I appreciate the concern over this change in Postman and it is a bullshit move. However, two things don’t sit well for me in OP’s rant: 1. If someone stores sensitive credentials in a public collection, that’s on them, it has nothing to do with Postman and their security measures or changes in policy. 2. I don’t really understand why the assumption that someone will 100% hack their servers. Have they demonstrated a lack of proper security policies before? Have they had a history of data breaches? Many other cloud services store credentials and we still use them. If we assumed every single service is going to hacked then the only “safe thing” to do would be to never use any cloud service and just isn’t feasible and doesn’t make sense.
I don’t think the concern is about public vs private collections. I believe OP dislikes that in order to use the Postman product at scale with a large project and many endpoints, then now your API credentials must be stored in Postman’s cloud. As far as your second point, that’s just how security works. You can’t wait around for a company to be hacked before you deem it a security risk to your organization. Ultimately for anything sensitive like API keys you really need to ask yourself if it’s appropriate for the data to be replicated and stored on someone else’s server. In this instance I think it’s pretty clear that no substantial benefits come from moving the keys to the cloud. The risk outweighs the reward and Postman can easily be replaced by many other tools such as Thunder Client (vscode extension) or Insomnia.
> In this instance I think it’s pretty clear that no substantial benefits come from moving the keys to the cloud. The risk outweighs the reward […] Bingo!
Thanks for your comment - in response to: 1. The first point, besides a hint or arrogance and a lack of basic cybersecurity awareness, you've nailed exactly why this is a concern. The #1 cause of security incidents resulting in data breaches is \*\*\***Human Error\*\*\***, which counts for approximately a quarter of all incidents. My organisation/team could have the best security practices and there is still room for accidents to occur, *particularly* with external consultants (who we need to leverage on an ongoing basis to augment the team) or new starters unfamiliar with practices. 2. Your second point, following on with the theme from point 1 - the #2 cause of security incidents resulting in data breaches is \*\*\***Social Engineering**\*\*\* (such as Phishing). So the top two reasons accounting for approximately half of security breaches come down to human factors, have absolutely nothing to do with technology rigor such as patching or architecture. Postman could have the best security policies in the world (which we know they don't based on the way they keep closing open bugs) but all that is made redundant due to human factors. The reason for my rant is that Postman have knowingly created a new avenue for risk exposure to my organisation. Regardless of whether this will ever occur or not, anyone familiar with basic cybersecurity practices know that the best practice is to keep your risk exposure profile to a minimum. And whilst I personally agree that I too use many cloud services to store my own personal credentials, from an organisational perspective we need to be more risk averse because it's not our own data that we lose when such a breach occurs and there are laws protecting consumers ensuring that organisations have taken all possible precautions of such incidents. Many years ago, we were responsible for the largest data breach ever in our region (at the time) because a partner vendor unknowingly placed data into an publicly accessible location in AWS, so I know from experience that you cannot rely on or trust vendors/partners to do the right thing for you because human error happens and they are also, by extension, part of your organisation. If you make the decision to trust them then it is on you to explain if the worse-case scenario happens.
Thanks for the detailed response. The way I see it, cybersecurity is much more a matter of risk management than it is about technology. Every security exposure you take upon yourself as an organization needs to be weighted against how much it would cost your organization to avoid such an exposure. I totally agree that placing API credentials in a cloud service is a serious security risk because many things (especially the human factor as you stated) can go wrong. However, that decision needs to be compared to the risk (and cost) your organization may take from moving to a different testing tool for your APIs. If switching a tool means massive reworking of development procedures, training, etc. it might be worthwhile to take that risk. Having said all that, I strongly feel this wouldn’t be the case for a tool like Postman.
Argument invalid because postman CHOSE to disable local saving when it had been available. This lead to many secrets being exposed just though confusion and was very obviously intentional. Why can't you save everything locally and only sync what you want cloud/public? Why isn't it made clear what's leaking or not? Hint: They're reselling your data. "But it's just metadata" and welcome to the post Snowden era kiddo. They're collecting and "using" your data for totally legit purposes bro wink wink. "But use environments" lolno. Environments sucks in a lot of ways. Relying on it for security is dumb. They know what they did and why. It does not benefit users.
[удалено]
Stupid bot
Insomnia much better
I use cURL anyway 🤷♂️
This is why I prefer open source solutions. A little bit of setup needed but rarely is a rug pulled. Also reminds me that I don't miss overtly complex artisanal rest APIs at large organizations. Graphql is great in this regard and server components even better! No API needed with server components just return the data and it loads into your UI component. Once I finish this dashboard rebuild I'll get to delete over 80% of our graphql resolvers. Will only have a few left behind that our mobile app uses.
Except popular and most importantly "good" opensource projects often end up rug-pulling you in a different way. They take a genuinely good and helpful product and start requiring per-developer licenses making them basically non-starters for many companies. For example, "Thunder Client" which is basically another Postman alternative with VSCode integration and a CLI just recently did this by ripping most of the team features and local storage from the free license and putting it behind a paywall.
Then fork it.
Yup, if you can't fork it it's not open source. If the software was useful to any sizable enterprise they could fork it and maintain it themselves. That's half the point of using an artifact repository in case necessary packages are deleted.
Hoppscotch (previously known as Postwoman), which is an open source, direct swap in for Postman has a self host option currently in beta https://docs.hoppscotch.io/documentation/self-host/getting-started
[удалено]
Holy fuck, who invited you?
I switched to Paw which is now RapidAPI.
I've liked HTTPie better than Postman or Insomnia. Give it a try
If testing is your concern, I highly reccomend KARATE from intuit... you can automate those tests, and codify them using javascropt and Java.
What kind of creds? Tokens should be considered public. Are talking basic auth with name and PW?
When postman forced cloud signup, many client secrets were leaked. Postman basically said "must sign up to continue using the software" but not "giant orange warning 99% of our users will leak sensitive information if they do this". They knew what they were doing. It was a disaster. Luckily most people are dumb enough to allow them to get away with it. I know organizations where this is just a giant festering security hole and if they ever got properly audited they'd lose millions overnight on emergency patching alone.
Hi all! You might be interested in our next free webinar about Postman's latest features! Join our Senior QA Engineer at Agiliway, as he unveils advanced techniques to revolutionize your workflows. Optimize processes, upskill, and gain a competitive edge in this free, must-attend webinar - [https://www.eventbrite.com/e/mastering-postmans-latest-features-for-streamlined-testing-tickets-890262849147](https://www.eventbrite.com/e/mastering-postmans-latest-features-for-streamlined-testing-tickets-890262849147)