I stopped using Postman when it magically started connecting to a central server for… nothing useful, really. I have no idea why people would design software this way, especially a development tool that should work with any web server, under any network condition (including fully offline against localhost).
Now I just have a Makefile with a bunch of curl invocations, or Python tests with requests to match against expected responses.
We went with a mix of curl, Invoke-WebRequest, favourite scripting language, HTTP files, IDE tooling, Insomina, after Postman went cloud online and became a forbidden tool on our systems.
Also I am not counting that Insomina won't follow the same footsteps as Postman.
I wrote my own api invoker, https://placeholders.cc/api-invoker/, mainly because postman is slow, eats a ton of memory and it becomes more and more restrictive to non logged in users. In don't mind having an electron based application like open. but i hate to have 10 like it open in the same time.
+ 1. I just came across it a few months ago after getting fed up with Postman's unintuitive ever-changing UI, etc. So far so good. Easy to store bruno files in a repo to have a nice easy place to go to get test calls
tried it but had some buggy interface when i used it full-time earlier this year. (albeit i work in a slow vm)
it might have changed now but it did not support grpc endpoints, which was a dealbreaker for me. but definitely appreciate the project and i hope it reaches core feature parity soon.
People that want to make money on their software obviously.
Connecting to a license server is pretty much standard.
For Postman it is annoying because it was never explicitly stated and it seemed like they are cool kids making nice helpful app. But really they are in for money. Which is not bad have to say but the way they did it is bad.
I think they started as cool kids and they changed their mind on the way. I'm using postman for a long time. I liked it, i preferred the online version, slowly slowly they started to push users towards the app, making it harder and harder first to use it without and account, then to use the online version. This is how I ended up with a heavy desktop app, when i needed something simple and easy to use.
I get the whining, but teams need ways to share their complex workflows, and teams are where the money is for all dev focused software.
That's who pays for all your tools to have free versions.
People who use make and curl to jury rig some unshareable solution together that no-one else in their company would even bother trying to use aren't worth any money to companies.
Teams that are knowledgeable jury rig their own custom solutions without all the enterprise cruft. They make solutions that fix their problem and they do it faster than the teams who use bloated enterprise solutions.
I am tired of seeing over engineered enterprise solutions that that are implemented and never used because they can’t be integrated into the dev workflow easily. Simple bash script that does the task it was designed to do beats any enterprise crap.
>I get the whining, but teams need ways to share their complex workflows, and teams are where the money is for all dev focused software.
Complacent corporate teams. Agile teams need to simplify their workflows, and know that a Makefile can be better than some closed down, Cloud-first tool.
>That's who pays for all your tools to have free versions
Nah, we have free versions for stuff without enterprise editions too.
>People who use make and curl to jury rig some unshareable solution together that no-one else in their company would even bother trying
> (...) teams need ways to share their complex workflows (...)
Apps like Postman are the wrong tool for this purpose.
If you want to share workflows, let alone complex workflows, any automated test suite is far better suited for this purpose.
We are in the age of LLMs and coding agents, which make BDD-style test frameworks even more relevant, as they allow developers to implement the workflows, verify they work, and leave behind an enforceable and verifiable human-readable description of those workflows.
To be fair, Vim and Curl are almost certainly dynamically linked, so they get to "cheat" a little. 10 megs is entirely reasonable for a statically linked utility intended to "just work" when you dump it somewhere in your $PATH.
Take the Micro editor. It's written in Go, and packs a fair bit of functionality into a single 12 meg static binary (of which a few megs is probably the runtime.)
Wow, I've been looking for a postman/Bruno/foo replacement that I could use inside a remote ssh server or remote dev containers in vs code. This might be it!
Oooh this is neat! I've been using hurl (https://hurl.dev/) for the last few years and while it's fun, I've ended up with a ton of text files floating around a folder instead of any kind of organization. Might have to try this.
A little bit of feedback, I could barely read any of the text in the interface as the contrast is almost zero and the font is unbelievably small. So I tried Cmd+ to zoom the interface, but nothing happened, so I tried Cmd, to open the settings to see if there was a zoom level or contrast setting, nothing happened. I like the idea of it, but it's totally unusable.
Voiden looks really promising, so I installed it to get started, and here's my hot takes so far before even using it.
* The text is tiny for my old eyes. I figured there's probably a setting for it and hit Cmd-, and found there's no settings UI whatsoever. No keyboard shortcut either it seems, and no help menu either, so no searching for "keyboard" with Shift-Cmd-/
* .void files may be markdown, but no markdown editor will recognize it as such. Maybe support .void.md as well. I also couldn't find any way to edit the markdown source of a .void file from voiden, which is a bit ironic for a tool that loudly advertises the markdown format as a central feature.
* Could there be a block that expands into the full URL of the request and parameters above it (or perhaps as args)? How about another that renders as a cURL command, which would cover POST/PUT/PATCH requests nicely too. My API documentation always has cURL request examples and I detest writing them by hand.
* While I'm suggesting blocks, one that renders the response headers/body to the preceding request would also be handy. It should support a placeholder response that gets replaced when the request is actually run (and perhaps a "save" button to persist it in the markdown). Responses get long, so maybe have a max-height for the block and make it scrollable
I'm actually really excited about Voiden and hope these can be addressed. It has a similar feel to Jetbrains' .http format, but an evolutionary leap beyond it. It also feels really raw and unfinished.
Hi, thx for the feedback!
Testing the settings (including different themes and font sizes as we speak).
Some tweaks are been made on the responses side as well.
As per the rest of your comments, some of these things have been discussed or touched upon, others have been just added to the discussion board :)
A lot of organizations have very large suites of postman collections that serve as API documentation, regression and QA testing… they often heavily rely on the postman Javascript libraries and have custom code embedded directly in the collection.
RubyMine, and I assume its cousin JetBrains IDEs, has a great HTTP client (Tools -> HTTP Client) that I've used when I need this sort of functionality. I've been off of Postman for quite some time, since it got so complicated, and all I wanted was something to help me make simple web requests. (No disrespect intended to those who like Postman, it's just too overwhelming for my needs.)
> RubyMine, and I assume its cousin JetBrains IDEs, has a great HTTP client
It's great. You can even paste a curl command into it and it will automatically convert and format it. You can then use the Copy button to convert your changes back to curl.
I think for the most part everyone has accepted that Postman grew into a monster that bloated with features and presumably that comes with online dependence.
$dayjob sent an email to everyone with postman installed and asked us to uninstall when postman switched to online. $dayjob IT still maintains a wiki page and includes it on the banned software list. Used to be ubiquitous over there.
Been using Yaak for 6-9 months now, initially built from source, but now a paying subscriber. Recently saw that you post open metrics[1] on subscriber count and revenue, and love getting a little look behind the curtains.
Curious to know more about the commercial licensing scheme for Yaak: if i’ve read correctly, purchasing a pro license if based on « good faith » as the features are exactly the same as the MIT licensed Hobby version?
Sincere question, been studying lots of OSS commercial licensing and always wonder what works in which context
Yes, it's a good-faith license. The license doesn't even apply to the OSS version (only prebuilt binaries).
The bet is that super fans will pay for it in the early days and, as it gets adopted by larger companies, they will pay in order to comply with the legalities of commercial use. So far, it's working! The largest company so far is 34 seats, with a couple more in the pipe!
If I asked my security team could I use yaak, they would (probably) say yes, and legal would say under no circumstances am I to use a personal license, they will pay for a commercial license. Large companies are incredibly risk averse when it comes to stuff like this.
This looks great. If you can wait 8 years before you sell out, that should be long enough for me to retire. Give me a headsup if they offer you a billion earlier so I can start looking for Yaak's replacement.
You should consider updating your free license to allow some time period of professional use, otherwise it's not possible to evaluate it at work without violating the license.
It's possible if you build from source, even in the commercial environment. As the last item in the pricing page says, the license only applies to the prebuilt binaries.
I was looking at Yaak, and wondering if you've plans to bring it inside VS Code some day?
how would someone use this in a project that operates within VS Code Remote where the source sits on a remote server and isn't physically on the file system.
off topic, sorry: Looking at the docs and I don't find a quick answer. I really want an API client that will do OAuth and handle token refresh, and I haven't found one. The use case is that (obviously) I control the redirect URI, so I'd like to map it back to client (some kind of proxy that I run and make external with all of the requisite DNS and TLS) or maybe via a hosted service (which I'm willing to accept for the convenience.)
I haven't used postman or insomnia in a while since they went to the cloud, so I could just be missing it, but that's also a non-starter for me.
Hey @gschier this is awesome. I've been a long time user of Insomnia and since the acquisition it's ever so slowly, well... it's been a challenge for me.
I didn't know you created Yaak!
I just downloaded Yaak and it's been awesome, thank you!
I downloaded this through AUR on Arch and one bit of feedback is that I wish you'd make the sig verification a whole bunch easier, thanks!
Can you provide clarity on is a commercial license is needed. The license appears to be MIT but the yaak.app website gives the impression a license is required, even stating as such in FAQ.
The commercial license terms only apply to the prebuilt binaries. You can build and run the OSS version for whatever purpose you'd like. Check the last FAQ on the pricing page
Hey Greg! Can you clarify that building from source and using in a commerical environment is permissable under the MIT license? I have built from source and yet the program is under "trial mode" currently and looks to have a 30 day ticker of doom. Is this a bug? Is there a flag missing? I cannot find any detailed instructions on setting flags or environment variables to turn this off.
Quick request, if it's doable: would you mind making a portable version of this? We're super locked down on our machines (even as developers), and all programs that need to be installed need to be approved. Portable programs fly under the radar, so they're easier to try discreetly, then we can make an official request to get them approved or buy a license.
Edit: oh my, you also made Insomnia, that I used when Postman was on the enshittification path...
This looks awesome! I've been wondering what to do with Insomnia since its enshittification.
One idea: since you are doing good-faith licenses anyway, maybe you could add in the possibility to pay for some kind of one-time license? I don't particularly need or want updates from my API tool, I just want it to work and not break. I would be fine with paying a one time commercial license that gives non expiring right to use a particular version.
One thing I despise about postman is how much friction there is to creating a new request. In my line of work, I'm often using an API client as a scratch pad to validate /poc. At the same time, it would be nice to just have a simple "history" that I could go back and search if I needed to find some request I made a few weeks ago.
Readit News
Now I just have a Makefile with a bunch of curl invocations, or Python tests with requests to match against expected responses.
Also I am not counting that Insomina won't follow the same footsteps as Postman.
There are several FOSS command line tools that can do this easier, e.g. https://httpie.io/cli
1: https://www.usebruno.com/
But the UX is just terrible (for me) or at least has been every time I've tried to start using it more.
I mean, come on, the most basic use of creating a request goes like this:
1. Sorry, can't let you create a request before you create a collection.
2. Sorry, can't let you create a collection before you make a decision on in which path you will be storing all your collections.
3. Sorry, can't let you create a request before you think of a good name for it.
etc.
Like what the heck? This should be just one click to create a new untitled request then fill in the URL and send.
At first I thought this might be growing pains since it was new but every year I try it and it hasn't improved.
it might have changed now but it did not support grpc endpoints, which was a dealbreaker for me. but definitely appreciate the project and i hope it reaches core feature parity soon.
Connecting to a license server is pretty much standard.
For Postman it is annoying because it was never explicitly stated and it seemed like they are cool kids making nice helpful app. But really they are in for money. Which is not bad have to say but the way they did it is bad.
I get the whining, but teams need ways to share their complex workflows, and teams are where the money is for all dev focused software.
That's who pays for all your tools to have free versions.
People who use make and curl to jury rig some unshareable solution together that no-one else in their company would even bother trying to use aren't worth any money to companies.
Teams that are knowledgeable jury rig their own custom solutions without all the enterprise cruft. They make solutions that fix their problem and they do it faster than the teams who use bloated enterprise solutions.
I am tired of seeing over engineered enterprise solutions that that are implemented and never used because they can’t be integrated into the dev workflow easily. Simple bash script that does the task it was designed to do beats any enterprise crap.
???
Mash 'em, boil 'em, put 'em in git, next to your code?
Complacent corporate teams. Agile teams need to simplify their workflows, and know that a Makefile can be better than some closed down, Cloud-first tool.
>That's who pays for all your tools to have free versions
Nah, we have free versions for stuff without enterprise editions too.
>People who use make and curl to jury rig some unshareable solution together that no-one else in their company would even bother trying
It's that "no-one else" that doesn't bring value.
Apps like Postman are the wrong tool for this purpose.
If you want to share workflows, let alone complex workflows, any automated test suite is far better suited for this purpose.
We are in the age of LLMs and coding agents, which make BDD-style test frameworks even more relevant, as they allow developers to implement the workflows, verify they work, and leave behind an enforceable and verifiable human-readable description of those workflows.
Git is pretty good at sharing you know
Edit: Ah, so here it is: https://posting.sh
Wow, in a world dominated by gigabytes of electron application, people thinks 10 MB is the optimal size for a simple utility TUI app.
As a reference, (from archlinux repo), vim’s install package is 2.3MB, curl is 1.2MB, lua (the complete language interpreter) is 362KB
Take the Micro editor. It's written in Go, and packs a fair bit of functionality into a single 12 meg static binary (of which a few megs is probably the runtime.)
Probably because it began as an chrome addon before it was "standalone".
Anyways, the folks have spoken, no need to double down. There are more than a dozen alternatives to it, and new ones are coming up.
I'm helping build a new one.
- Completely offline.
- Gives the ability to build reusable blocks (headers, query params, etc)
- Let's you document everything in Markdown.
- Imports your collections and cURLs.
https://voiden.md/
The CEO committed to open-sourcing it, as well as to not monetize on anything that doesn't introduce operational costs to the team.
https://voiden.md/blog/why-we-rebuilt-bloated-api-tooling
What you're saying doesn’t sound familiar whatsoever, but I'd really like to look more into it.
* The text is tiny for my old eyes. I figured there's probably a setting for it and hit Cmd-, and found there's no settings UI whatsoever. No keyboard shortcut either it seems, and no help menu either, so no searching for "keyboard" with Shift-Cmd-/
* .void files may be markdown, but no markdown editor will recognize it as such. Maybe support .void.md as well. I also couldn't find any way to edit the markdown source of a .void file from voiden, which is a bit ironic for a tool that loudly advertises the markdown format as a central feature.
* Could there be a block that expands into the full URL of the request and parameters above it (or perhaps as args)? How about another that renders as a cURL command, which would cover POST/PUT/PATCH requests nicely too. My API documentation always has cURL request examples and I detest writing them by hand.
* While I'm suggesting blocks, one that renders the response headers/body to the preceding request would also be handy. It should support a placeholder response that gets replaced when the request is actually run (and perhaps a "save" button to persist it in the markdown). Responses get long, so maybe have a max-height for the block and make it scrollable
I'm actually really excited about Voiden and hope these can be addressed. It has a similar feel to Jetbrains' .http format, but an evolutionary leap beyond it. It also feels really raw and unfinished.
[0]: https://www.jetbrains.com/help/idea/http-client-in-product-c...
[1]: https://learn.microsoft.com/en-us/aspnet/core/test/http-file...
[2]: https://marketplace.visualstudio.com/items?itemName=humao.re...
Thus, we stick with hurl.
QA seems to stick to robot framework instead. Some use Bruno.
Converted a bunch stuff just laying in my shell history into actual actionable files finally :D
It's great. You can even paste a curl command into it and it will automatically convert and format it. You can then use the Copy button to convert your changes back to curl.
It used to considered vile that drug dealers tried to hook their users and force dependence... turns out that they were just ahead of the curve.
It brought to mind this quote:
“It’s only software developers and drug dealers who call people users,”
From a recent article that came through the feed:
https://www.theguardian.com/technology/2025/oct/18/are-we-li...
https://news.ycombinator.com/item?id=45626691
I hate it, for myself I don’t use it but when having to share API stuff I have to use it because that’s what other people understand.
Good for postman business, bad for everyone.
https://yaak.app
[1]: https://yaak.app/open
Deleted Comment
Sincere question, been studying lots of OSS commercial licensing and always wonder what works in which context
Yes, it's a good-faith license. The license doesn't even apply to the OSS version (only prebuilt binaries).
The bet is that super fans will pay for it in the early days and, as it gets adopted by larger companies, they will pay in order to comply with the legalities of commercial use. So far, it's working! The largest company so far is 34 seats, with a couple more in the pipe!
how would someone use this in a project that operates within VS Code Remote where the source sits on a remote server and isn't physically on the file system.
I'm not quite sure why Yaak wouldn't work in this case. It it because your running server wouldn't be accessible to Yaak, running on your system?
I haven't used postman or insomnia in a while since they went to the cloud, so I could just be missing it, but that's also a non-starter for me.
Also, it’s an amazing app.
> Having created and sold Insomnia in 2019
I didn't know you created Yaak!
I just downloaded Yaak and it's been awesome, thank you!
I downloaded this through AUR on Arch and one bit of feedback is that I wish you'd make the sig verification a whole bunch easier, thanks!
Can you provide clarity on is a commercial license is needed. The license appears to be MIT but the yaak.app website gives the impression a license is required, even stating as such in FAQ.
Thanks!
And yes, you can indeed run the OSS yourself for commercial purposes.
Edit: oh my, you also made Insomnia, that I used when Postman was on the enshittification path...
One idea: since you are doing good-faith licenses anyway, maybe you could add in the possibility to pay for some kind of one-time license? I don't particularly need or want updates from my API tool, I just want it to work and not break. I would be fine with paying a one time commercial license that gives non expiring right to use a particular version.
These api clients are rocket science, the barrier for entry is very low.