API clients play a crucial role in our daily work. They help us test, debug, and easily use APIs. For many years, Postman was the gold standard and the tool of choice. In fact, the question of which client to use for API work never even arose. Postman was simply ubiquitous and used by everyone, no matter where you looked.
However, this changed significantly in May of this year: Postman announced in a blog post that there would be a new “lightweight API client” (and that the “Scratchpad” would be discontinued). Initially, this announcement seemed irrelevant, as it was only about deprecation. The situation became more problematic when the Postman app, after new installations, no longer included the feature, which was also set to be removed from existing installations starting in September.
Sooner or later, we would have to look for alternatives.
But let’s take a step back: what is the issue with the new lightweight API client or with Postman overall?
Postman’s Development as a Problem
For some time now, Postman has evolved from a mere API client to an API platform that offers many different functions. Synchronisation and collaboration have become increasingly important. There is no doubt that this offers many advantages and great opportunities – if you can or are allowed to use them. However, this is where the problem lies: we work with and on our clients’ APIs. We cannot simply upload and store all data in the cloud unless the tools used are explicitly approved.
For example, this is not the case with Postman, for example. All data must therefore be stored locally and can only be exchanged via Git repositories, potentially encrypted.
Previous Solution
Until now, we were able to use Postman without any issues by simply not utilizing the cloud functionalities. This only required refraining from creating a user account. As a result, nothing was synchronized with the cloud, and all data was stored locally. For team collaboration, we manually exported Collections and Environments, stored them in Git repositories and imported them back from there.
While this wasn’t particularly convenient, it worked seamlessly for a long time. The separately stored environment files also allowed us to exchange passwords and other sensitive information in encrypted form. Since we worked outside of Postman at the file level, we had complete flexibility: some used SOPS, while others preferred git-crypt.
The method chosen for encrypting individual files had no impact on the work within Postman itself, so I won’t go into further detail here.
Postman Lightweight API Client as a Non-Alternative
The introduction of the new “lightweight API client”, as the official replacement for Scratchpad, has effectively rendered Postman unusable for us in the long term.
This highly touted new client is indeed just a client and lacks almost all the essential functionalities we require for our work, especially the ability to create (structured) collections of API requests and manage parameters and variables in environments.
The new client offers none of this; essentially, it is just a graphical alternative to curl.
Of course, the features are not gone. The catch is that you now have to be logged in to use them. And once you log in, all data is automatically uploaded and stored in the cloud. No exceptions, no prompts and no way to prevent this. An absolute no-go!
Disabling automatic updates in Postman or installing older versions only provides a temporary solution. On one hand, we don’t want to use potentially outdated software indefinitely; on the other hand, Postman has, on several occasions, ignored the settings for automatic software updates and forced the new version on us, complete with the unwanted changes.
So, at best, we have only bought ourselves some time to search for alternatives.
During this time, it also became clear that Postman has no interest in supporting offline functionalities. Requests for such features are either ignored or rejected. Old versions have even been removed, making them no longer available for installation.
We had to find an alternative!
Use Cases and Requirements
In searching for an alternative, we initially considered the use cases we covered with Postman and the requirements we had for an API client.
Context
The tool we are looking for must be deployable within a consulting firm context. This entails usability for both client-side and internal teams.
It’s crucial that sensitive information is handled securely to maintain confidentiality agreements. Specifically, this mandates no data uploads to the cloud. Instead, the capability to store data locally and facilitate export/import operations is essential for team collaboration.
Additionally, seamless integration for importing Postman collections and environments would greatly aid in migration efforts.
Furthermore, given the deployment context, the API client we are seeking must be available for all major operating systems, including macOS, Linux, and Windows.
Incidentally, the primary focus is on HTTP-based web APIs (REST APIs). GraphQL, gRPC, and similar technologies are not within the scope of our search, although support for them would certainly be beneficial.
Functions
The following list of functionalities is not exhaustive but aims to give a general idea of what we are looking for:
- Ability to organise API requests into collections, ideally within projects or workspaces.
- Support for collections with folders, including nested folders, to organize APIs, tests, or maintenance workflows based on systems, categories, etc.
- Availability of multiple environments (restricted to the workspace/project), such as DEV, Staging, and Production. While nice-to-have, environment settings at the collection and folder level are not mandatory.
- Support for authentication mechanisms, including HTTP Basic Authentication, API Key, OAuth 2.0 with Client Credentials Flow and Authorization Code Flow, as well as client certificate authentication.
- Capability to set request parameters based on the response from a previous request (pre-request scripts).
- Ability to set header, path, and query parameters directly as “real” parameters, without needing to use variables from the environment. For example, for a request to fetch a user by ID, it should be possible to use
GET /users/{userId}userIdis specified for the request, rather than needing to useGET /users/a2b8ef58-ae0a-474a-84da-dc156bcce6b8.
A command-line interface for automated execution of requests (and tests), such as with Newman or Postman CLI,, is a bonus but not the primary focus.
Our search for alternative API clients has primarily centered around manual interaction with APIs, rather than automation.
Alternative API Clients
After extensive research and testing of various API clients, I can recommend the following tools:
- Insomnia
- Insomnium
- Kreya
- Testfully
- Bruno
While not all of them meet every requirement in the same manner, they are all capable of covering most of our use cases. In some respects, they even make a better impression than Postman.
Insomnia vs. Insomnium
Before delving into the specifics of each tool, it’s important to discuss Insomnia and Insomnium in more detail, as they are key for comparing and considering alternatives to Postman.
Insomnia has been in existence for several years and was acquired by Kong in 2019. It is an open-source project released under the MIT license. Over the years, Insomnia has evolved into a powerful API client that offers some features not available in Postman.
However, just a few days after Postman discontinued the Scratchpad, Kong significantly upset the Insomnia community: with the introduction of Insomnia 8, there was suddenly a de facto requirement for accounts and cloud synchronization – like what had happened with Postman before.
While Insomnia can still be used without a user account, it is restricted to a single project. This limitation significantly impacts its everyday usability, turning Insomnia from a potential ideal alternative into a fallback solution.
Shortly after these significant changes to Insomnia, Insomnium was launched as a fork. Starting from the last Insomnia version without cloud and account requirements, Insomnium is dedicated to providing complete offline functionality. Furthermore, the project aims to overhaul or rewrite essential aspects.
There are no plans to merge back into Insomnia. Although the two projects are still closely aligned, the lead developer of Insomnium has intentionally chosen to pursue a separate path.
Overview
The following table provides an overview of the key features and their support in the respective API clients we have examined.
The symbols used have the following meanings:
- ✅: Supported
- ❌: Not Supported
- 💰: Available only as a paid version
- (✅): Supported, but with limitations or through additional plugins
- (❌): Not supported but achievable through alternative methods
It becomes clear that the perfect API client (one that does not automatically synchronize all data to the cloud) does not seem to exist at the moment.
Highlights
The considered clients emphasize different aspects, some of which have unique features. If your work focuses on these areas, it can significantly influence the decision for a particular client.
Insomnia and Insomnium
For example, Insomnia and Insomnium stand out due to their extensive import capabilities (in addition to the formats listed in the table, these tools offer additional import options). This makes them suitable migration options for a variety of scenarios.
Furthermore, the client’s functionality can be flexibly expanded through plugins, either from the official plugin collection or through custom plugins.
The original project and its fork currently differ mainly in their support for cloud and team functionalities in Insomnia, which have been removed in Insomnium. In the current version of Insomnia, users can choose whether projects should or can be synchronized or stored locally. However, this requires a user account, which was initially a criterion for excluding the tools considered here.
Insomnia is primarily chosen because it was our initial, agreed-upon alternative to Postman, we had already completed the migration, and with the current version, cloud synchronization is no longer mandatory, allowing us to continue using the tool.
Insomnium, on the other hand, does not offer such functionality; it only includes built-in Git integration for data exchange. Instead, the focus of its further development is on stability and performance.
There are no plans for Insomnium to merge back into Insomnia. Both projects are intended to be maintained independently.
Kreya
Kreya offers a unique option for working with API specifications: Importing is not just the starting point for creating a collection; the project is continuously synchronized with the specification. Furthermore, authentication is globally configured and does not need to be set individually for each request but is referenced centrally. This makes Kreya particularly suitable for new projects based on an API specification that do not require migration from another tool.
Testfully
Testfully is heavily focused on API testing. In Testfully, collections do not contain API requests per se; instead, they consist of tests that involve multiple steps or requests. Configuration options for executing collections include various variable sets and different execution orders, including parallel execution of requests.
Bruno
Bruno claims to be a revolutionary API client that prioritizes local data storage. Collections and requests are stored directory and file-based, with requests described in a proprietary markup language also supported by Bruno CLI.
What sets Bruno apart is its high frequency of releasing new versions, surpassing all other tools considered here. While some essential features may currently be (yet) unimplemented, they are on the roadmap for future updates. Despite this, the tool has already gained considerable popularity.
Our Alternative
Which API client do we use now?
As mentioned earlier, we have already decided on using Insomnia, and some of our clients have followed this recommendation and migrated with us. The transition from Postman to Insomnia was not without its challenges and pains, which must be honestly acknowledged here. Here are a few examples:
- Initially, references to environment variables from Postman were not correctly imported into Insomnia collections, requiring manual adjustments due to different syntaxes.
- Some client certificates that worked flawlessly in Postman initially did not in Insomnia.
- Insomnia still lacks native support for path parameters, necessitating the choice of one of three available plugins.
- Pre and post request scripts had to be recreated in Insomnia using request chaining wherever possible.
In discussions about Postman alternatives, Insomnia was sometimes referred to as the “least of all evils.” However, we have arrived at a largely functional setup that we can now continue to use.
We were dismayed and frustrated when Kong introduced significant changes overnight. This prompted us to resume our search for alternatives.
Unlike Postman, Kong responded to the outcry and community feedback by making adjustments that allowed Insomnia to continue being used, while Insomnium emerged rapidly as an alternative.
Both tools are currently in use within our organization, and interoperability has not been an issue since they operate on the same data format and the data can be exchanged without any problems.
It’s worth noting that we are observing Insomnium with a healthy dose of skepticism or caution, given that it’s a very young project and its long-term sustainability remains to be seen.
The other tools presented here may offer interesting approaches but were only considered for overview and comparison purposes:
- Kreya does not offer a migration path for our Postman or Insomnia collections.
- Testfully is too focused on API testing for our primary use cases or lacks support for client certificate authentication, making it unsuitable for all projects.
- Bruno lacks OAuth authentication support, ruling it out for productive use in our projects.
Summary
We have examined changes in the field of API clients, particularly in relation to Postman, and the associated challenges regarding data privacy and local storage.
We explored various alternative API clients along with their supported functionalities to align them with specific use cases and requirements. Ultimately, we decided on using Insomnia (and/or Insomnium). Both provide the necessary feature set, and the migration was already completed when the world of API clients was once again thrown into uncertainty.
Fortunately, Kong corrected its short-term decision, and Insomnium emerged as a young but currently fully compatible alternative. Other tools presented here are not further considered due to specific requirements or the practicality of existing solutions already in place. The future development remains to be seen.
Overall, the article provides an overview of promising options in the API client landscape and offers insights and suggestions for those seeking an alternative to Postman.
