API Clients for Testing and Beyond - Alternatives to Postman (and Insomnia)

The first thing to note is that I am looking for a tool that can be used in the corporate environment of a consultancy company that works with large enterprise customers. Teams on both sides, the customer and the consultancy, need to be able to work with the tool.

Due to the nature of the business, the tool needs to be able to handle sensitive data, and it needs to be able to be used in a way that does not violate any data protection regulations.

We already have our collections and environments set up in Postman, so it would be great if we could import them into the new tool without too much effort.

By the way, the main focus are HTTP web APIs. GraphQL, gRPC and the like are not in scope of the search, although it would be nice to have support for them, of course.

In short, the requirements based on the context are:

The following list of features is not exhaustive but should give you a rough idea of what I am looking for:

Postman is the tool that started it all, and it probably is still the most popular tool for working with APIs.

However, this is the only reason it appears on the list of alternatives. It is not just that I do not like the direction Postman is going and do not want to use it anymore.

In fact, I tried to use at least their new and shiny "lightweight API client" as an alternative, but it failed miserably as I could not even import an OpenAPI spec file.

Without an account, Postman is not usable anymore, and with an account, all data is synced to the cloud — absolutely no-go and deal-breaker for me.

At the moment, Insomnia still seems to be the most-promising alternative to Postman, although a quite annoying one lately.

A lot of well-known functionality from Postman requires is not supported out of the box, like request tabs or "true" path parameters that can be set just like query parameters. However, there are plugins for many of these features.

In general, plugins are actually also a big plus of Insomnia: Want to use credentials from an Azure Key Vault, for instance? Here you go!

Coming from Postman, it took some time to get used to Insomnia but the built-in functions, the option to use variables in other variables, request chaining as an alternative to Postman’s pre-request scripts, or the on-the-fly execution of requests to acquire OAuth tokes are quite nice.

Nevertheless, I cannot look past the fact that Insomnia also has some noticeable bugs. All in all, it does not feel as stable and mature as Postman, and the fact that they basically went the "Postman way" does not make it more attractive either. This change without prior announcement and without any option to opt-out is quite a bold move and rightly upsets the community.

Insomnium is a fork of Insomnia that was created in response to the changes in Insomnia 8.0.

There is not too much to say about it because it is basically the previous version of Insomnia with everything network-related removed (user login, tracking, etc.). This new old version of the tool runs 100% locally now.

If you already migrated to Insomnia, you should be able to pick up where you left off with Insomnium.

However, time has to show if this fork will be maintained going forward, or if it will just preserve the last version of Insomnia as we knew it. At least there is the expressed commitment to maintain the fork and improve it long-term.

Kreya is very welcoming. When you open it for the first time, it lets you start with a sample project and takes you on a tour through its features. This is not just unique but also very smart and helpful.

It immediately guides you to the project settings, and you get to know that authentication can be configured at the project level to be referenced by requests.

Also, you learn about importers that can be run multiple times to keep your project up-to-date with the latest changes of the OpenAPI spec file, for instance. In fact, this is a feature I missed in Postman where a re-import would result in a new collection. I am really glad to find this feature in Kreya. Whether it is actually useful in practice (and working as expected), though, is a different question.

Right after the importers, Kreya tells you about its support for client certificate authentication.

While walking through the UI, from the settings to the operations view, it clearly and transparently points out what is a paid feature: scripting for defining tests, running pre-request scripts or for dynamically updating variables, for instance.

What is a bit uncommon at first is the need to define operations using relative request paths, like /users/{userId} with the base URL being defined at folder-level. However, this is actually not a bad idea as it is a good way to avoid duplicate configuration, and most collections are set up that way anyway — just with more redundancy.

And, yes, "true" path parameters are supported, and Kreya uses the same syntax as OpenAPI to define them in the request path.

All data is stored locally. Instead of a giant JSON or YAML file, Kreya uses the folder structure from the collection also on the file system. There is a folder for folders, a file per request, and environment, etc. Different file extensions are used which allows for easy and targeted configuration of encryption, for instance.

This all sounds too good to be true, right?

And it is, unfortunately: Users who depend on the ability to use pre-request scripts and post-request scripts, cannot use the free version of Kreya at least.

Besides that, using Kreya is very good experience, literally relieving to see almost all required capabilities being supported out of the box, without the need to create an account. The way data is shared with others is completely left to the user, and the way data is stored locally is very transparent and easy to understand and obviously was designed with Git in mind.

Httpiness is special. It is mainly listed here because of its interesting approach to put HTTP requests into the focus. In fact, the user interface is very minimalistic and the request view is essentially based on the anatomy of an HTTP request.

Parameters play another essential role. They are organized in parameter presets (also known as environments) and can be user anywhere in requests. Also, parameters are shared across the entire collection. In essence, httpiness merges the concepts of environment variables and request parameters into one simple but powerful thing. This is definitely a nice touch.

Authentication configuration is also very simple: It is defined once as an independent object that is then used in requests.

All data is stored locally, and in one big JSON file.

However, httpiness lacks the ability to import OpenAPI specifications, and it comes with very limited configuration options. Setting client certificates, for instance, is not on the list. Importing OpenAPI spec files is also not supported. Importing Postman collections is available, though.

Httpiness' philosophy is to keep things simple, and it does that very well. It is targeted at developers who want to work with APIs alongside their development work, for instance to manually send a few requests to quickly test something. It is not trying to be a general-purpose API client with all kinds of bells and whistles, and in the end it turns out to be a very nice tool for its purpose.

Its simplicity put aside, the usefulness of httpiness can come to a sudden end when you attempt to fetch an OAuth access token: What is working in Insomnium, for instance leads to invalid grant or invalid client credentials errors in httpiness. That is definitely causes no happiness.

Advanced REST Client is a name that raises expectations. Knowing that it is from MuleSoft, does not lower them either.

After Kong, and also Postman nowadays, MuleSoft is another big player in the API space, and they are particularly known for their API management platform. So they should know what they are doing and what matters for API developers, right?

For sure, Advanced Rest Client indeed is an advanced tool. It is the first tool I found that supports the configuration of multiple authentication mechanisms for the same request, including client certificate authentication! For OAuth 2.0 authorization code flow, the required redirect URI is presented right away.

It also provided per-request configuration options for SSL validation, redirects, or even timeouts, and more. Capabilities unknown in other API clients.

However, the UI is not very intuitive. Therefore, I am not entirely sure if the confusion that follows is due to the tool or due to my lack of understanding of the tool:

Pre-request scripts and post-request scripts, or at least something similar exists that is quite powerful and very limited at the same time: Based on conditions, you can do very few things: set a variable, set a cookie, or delete a cookie. That is it.

To be honest, the scripts known from Postman or Insomnia plugins seemed way more powerful and flexible to me — more advanced, if you will.

Also, looking at the screenshot closely, you might notice that it does not mention parameters at all. Query parameter, path parameter, whatever. No worries, in the request URL editor menu, at least query parameters can be added, and URL encoding or decoding can be configured. No word about path parameters, though.

By the way, the export functionality is similarly confusing: You can export all data, or a project, or you call the export from a specific request. The all data export is highly configurable: Environments and history can be included or excluded, just like cookies, etc. The request export always includes the history without any configuration options, and the project export includes only requests, without history. Both have no further configuration options. All data and request export use JSON format, while the project export uses *.arc but the content is JSON with the same structure as from the other exports again. Confusing.

And the import of an OpenAPI spec file? Well, it is supposed to be supported but just did not do anything when I tried it with an OpenAPI v3.0.2 JSON. In the general data import, it says Open API spec projects can be imported from ZIP files that contain only the project. So I also tried that…​ No luck, although the app this time did not do nothing in this case, but it just crashed and closed without any error message. The import of Postman data at first looked promising, but the imported project then could not be opened and used:

Can I recommend Advanced REST Client? Well, I wish I could. It certainly is advanced, but being a viable alternative takes more than that.

Milkman is a tool that did not show up on any of the lists I found, so it is even harder to find than Kreya. Eventually, it appeared in another post on LinkedIn.

Also, Milkman is heavily inspired by Postman but came to live already a few years ago, the first release being in 2019. The motivation behind Milkman was to create a tool that is less hungry for resources than Postman, and all the other Electron-based apps. Milkman is based on JavaFX. Although programming languages and underlying frameworks were no focus of my search at all, and I did not really pay attention to that part, I realize the majority of tools are written in JavaScript or TypeScript.

Milkman provides workspaces that can optionally be synced with Git.

OpenAPI specifications can be imported, at least in YAML format, and Milkman automatically creates a collection — without folders, though. In a collection, new folders can be created to organize requests using various protocols, not just HTTP. GraphQL, gRPC, Websockets, and even SQL and CQL are supported.

However, giving Milkman a try I felt really stupid because I could not figure out how to create a new collection by hand without importing something (Postman and cURL are supported, Insomnia not, by the way). The documentation was not of any help either. It primarily focuses on plugins and the development of plugins. Just when I wanted to give up, and added my sample request to the collection of the imported API spec, I realized a collection is implicitly created when you save the new request in a "root folder" (collection) that does not yet exist. Okay, I can work with that.

Nevertheless, the user experience is not great. The interface is not really intuitive. How do you configure authentication for a request, for instance? You can configure OAuth authentication or API Key at the same "global" level as environments, but separately. The result, however, is similar: You get variables you can use in requests in the right place. For example, if you configured an OAuth secret, you can add an authorization header to your request and assign the value Bearer {{key:my-oauth-config}} to it. Uff, that is not exactly straightforward.

Another mystery is the authorization code flow support: You cannot configure a redirect URI, and everytime you attempt to fetch a token, another redirect is used (e.g., http://localhost:49789/ or http://localhost:49754). How am I supposed to configure the allowed redirect URIs in the OAuth client?

And, there is also no sign of HTTP Basic authentication or client certificate authentication.

Milkman supports scripting, though. JavaScript scan be executed before and after requests.

At first glance, Hoppscotch is an interesting option that started as a minimal and efficient open-source API client, actually inspired by Postman. Thus, the UI reminds of the old days of Postman. It is available as a web app or browser extension, and you can also host it yourself.

That, however, already feels a bit strange to me. Why does an API client have to be a web app running in the browser? Why does it have to be hosted on a server?

According to the webpage, a desktop client is coming soon, though, which might make Hoppscotch a viable option for everyone who has reservations about an "online" API client.

By the way, talking about online, Hoppscotch also lets you create an account and use cloud sync — this time configurable, though.

However, if you have the same requirements as we do, you will need to look further as it is still lacking support for client certificates.

Firecamp is another interesting API client that takes things to a new level.

The import of OpenAPI specs just works fine and automatically creates a collection with folders. I my API client exploration adventure, I learned to appreciate that already.

A unique extra feature of Firecamp are two kinds of environments that live next to each other: a workspace environment and a collection environment, this might be useful for selecting different request data or user profiles. However, I am not sure if the workspace and collection levels come in handy in practice here, or if they actually make things more complicated.

Unfortunately, we also will not figure that out as Firecamp is enforcing the creation of an account very aggressively at unseen levels and in unexpected places:

That is really sad and annoying for an otherwise promising tool.

It even supports the rarely found option to express path parameters as parameters, which is actually quite nice. It would be nicer, though, if these parameters would actually get set in requests in the end.

I do not know whether the use of path variables would just require a user account and being logged in (SCNR), or if it is a bug. At least, that is something that is simply not working, and not presenting a login modal.

Testfully clearly jumped on the bandwagon of the Postman announcement and announced their new offline mode shortly after. Actually, just like other tools, Testfully also lets you create an account and collaborate with others (and sync your data to the cloud).

The tool has a nice UI and is easy to use, but it is also a bit limited in its functionality.

Or to put it differently: It is a nice niche tool with a strong focus on testing, which is not a surprise given the name. It has some pretty neat features for testing in particular, validation of API responses or request chains look like first-class citizens, but it is not a general-purpose API client in general.

With that testing focus in mind, it also makes a lot of sense to find SSL certificate validation as a configuration option for environments, folders and requests. Also the type property of environments to indicate whether a VPN connection is required to use an environment, for instance, is a nice touch.

However, the import fails to import an OpenAPI v3 spec file, but Testfully is supposed to support Swagger, Postman and Insomnia formats. Unfortunately, there does not seem to be a way to export the data again, though.

And, I will probably just stop mentioning client certificate authentication. Instead, there seems to be good support for OAuth 2.0, including the authorization code flow. What stands out is that the configuration explicitly states the redirect URL that needs to be configured in the OAuth client.

What it also does not fail to state is that you need to upgrade to get the full experience, in several places:

HTTPie is a simple API client that might be sufficient for basic use cases.

You are dealing with complex APIs and would like to organize your requests in collections with folders and sub-folders? Sorry, HTTPie is not for you. There is no support for folders in collections.

You want to import an OpenAPI spec file? Sorry, HTTPie is not for you. The import only supports Postman and Insomnia formats (but not everything) — and cURL.

Authentication can be configured at level of the collection or for specific requests, which is actually quite nice but also not too helpful when there is no support for folders. And if you want HTTPie to acquire OAuth access tokens for you? Sorry, HTTPie is not for you. You can only set the token manually.

Lacking support for client certificates should not be a surprise at this point.

All in all, HTTPie is a nice tool for simple use cases, but it is not a viable alternative to Postman. It more or less is a nice cURL UI.

But: You can create an account to additionally get cloud sync. Yay! And, you can also create more spaces to organize your requests.

Without an account, you start with an "incognito space" that is kept locally but cannot be shared with others as there is no export option.

Bruno is on the list because it comes with the aim to "revolutionize the status quo represented by Postman and similar tools". This is also reflected in the Bruno Manifesto.

Instead of using YAML or JSON file formats to describe requests and collections, Bruno defines its own markup language which is designed to be Git-friendly.

While all that sounds pretty promising, you hit the wall pretty quickly when trying to use Bruno for real-world use cases. With that, nothing extraordinary is meant, just some very basic requirements when working with APIs:

It does also not help when Bruno is able to import data from Postman and Insomnia when it completely misses out on the authentication configuration. It is just not there anymore after the import.

There still is a lot of work to do before Bruno can be considered a viable API client.

The high goals, the little dog reaching for the stars, is worth a honorable mention, though as it is one of the very few tools that puts offline and local usage first. And, it does not even think of cloud sync.

Soap UI was the first API client I used for exploring and testing API (before switching to Postman) years ago. When looking for an alternative, I was actually mainly looking if SoapUI is still around — and whether it still relies on that weird XML file format that made collaboration quite difficult back then.

Oh boy, it is still around, and it still uses that weird XML file format. The whole experience could not be more frustrating (and different from the other tools I looked at):

The UI looks like it is from the 90s, and it is a mess. Resizing windows is a pain, and the UI is not responsive at all. Modals open everywhere and on top of each other. The font is hard to read, the cluttered UI is slow. Really, it is a mess.

It took me a long time to add even a single request to the project, or actually the service in the project. Honestly, I have a hard time understanding what is going on in SoapUI, and I really do not want to spend more time on it.

Supported authentication mechanisms? No clue. I do not even know where I should start looking for them.

I rather start looking for the world (or industry) in which the broad statement from the website is true: "The Industry’s #1 API Testing Tool".

To be fair, there is a huge amount of documentation. The Top 10 Tips for the SoapUI Beginner alone are more extensive than the entire documentation of other tools I looked at. Documentation is great, but it should not be necessary to read a book before you can use a tool, and the best documentation is useless if the tool is not usable because of awful UX.