API Testing Tools: Insomnia
In this post we will talk a bit about Insomnia, its main features, similarities and differences with other API testing tools.
What ‘s Insomnia?
Insomnia is a free, cross-platform desktop application that simplifies the interaction and design of HTTP-based APIs. Insomnia combines an easy-to-use interface with advanced features like authentication wizards, code generation, and environment variables.
The following chart compares the main features of Insomnia with Postman and SoapUI for similarities and differences.
|Free, Open Source & Pricing||Free & Pricing||Free, Open Source & Pricing|
|Desktop||Web & Desktop||Desktop|
-New Folder, Duplicate, Delete, Settings.
-Share, Run, Add Request, Add Folder, Edit, Monitor Collection, Mock Collection, View Documentation, Export, Rename, Duplicate, Delete.
-Authorization, Pre-request script, Test, Variables
-GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, CUSTOM
-GET, POST, PUT, PATCH, DELETE, COPY, HEAD, OPTIONS, LINK, UNLINK, PURGE, LOCK, UNLOCK, PROPFIND, VIEW
-GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, PATCH, PROPFIND, LOCK, UNLOCK, COPY, PURGE
|–||Mock Servers||Generate Mock Service|
First approach to Insomnia
My first tests with the tool were for this review, and the objective of them was to understand what features Insomnia has as well as to know first-hand how it handles both REST and SOAP APIs, therefore, these tests were carried out against the APIs GoREST and CountryInfoService.
Following the style of the previous post, Hoppscotch: Open Source API Development Ecosystem, we want to understand how Insomnia behaves by testing a Rest API versus Postman and a Soap API versus SoapUI.
I share some screenshots taken during the tests to show what the tool looks like. After downloading and installing it, its use is really intuitive since it presents an interface very similar to Postman.
Proof of Concept: GoREST
GoRest is a Rest API that is available online for testing and prototyping. It allows the registration of users who can publish posts and comments. As this is a testing API it only contains fake data.
To start testing GoREST, create a project in the Insomnia dashboard:
The first thing I did was configure the work environment. To do this, we go to the environments menu and select the Manage Environments or Ctrl+E option:
In the environment manager we display the options in Sub Environments and select Environment:
With the new environment created, we can click on the name to edit it and start writing the parameters in JSON format:
Once the environment is created, we must select it from the drop-down list:
Within the environment, we create the collections to organize and store the different requests:
Unlike Postman or SoapUI, collections or folders are not exported directly from the context menu, however, in Settings, they can be moved or copied to another Workspace.
To import or export any document or collection from the workspace, go to the menu that is displayed in its name and select Import/Export:
As in similar tools, parameters can be used in requests through environment variables, defined in JSON format.
To invoke any parameter, press Ctrl+Space where you want to insert it, and a list with all the available variables is displayed.
It is also possible to indicate the parameter directly in the Query section of the request:
In the case of sending a POST type request, as in other tools, you can select the type of Body (JSON, XML, YAML, EDN, Plain, Binary File, No Body):
In the case of the API we are testing, it is necessary to send an authorization token that can be added in the Auth section by selecting the type of authorization required:
Insomnia allows you to make requests from cURL. To do this, we copy one of the cURLs offered by the GoRest API as an example and paste it in the request URL:
Pasting the cURL automatically displays the URL:
Likewise, it is possible to send attached files if we select Binary File in the Body:
After selecting the file, the request will look like this:
The result can be seen on the right side of the screen as follows:
Another feature shared with other tools is the response history on the right to be able to trace our work:
Proof of Concept: CountryInfoService
It is a web service that displays country information from a two-letter ISO code, for example, “UY”. It offers functions to recover the currency used, the language, the capital city, the continent, and the telephone code.
To get started, I created another project in the Insomnia dashboard. I also configured the environment and collections of the new Project:
For requests of the SOAP type, what we do is select XML as the Body type and give it the corresponding format (XML):
An important thing: we must select the POST method, although it is possible to use GET in Soap web services, typically, given that this protocol uses verbose payloads, POST is usually used. In addition, it is also necessary to configure the headers:
And we get the answer:
If we prefer to pass data as parameters in the request, we can do it as follows:
Insomnia allows to extract values from the answers to be used in other requests. For example, using the response ID of a POST method in a GET request. You can see this Documentation for more information.
There are three types of response options:
- Response – Body Attribute: Works on JSON and XML responses, pulling attributes from a response body.
- Response – Raw Body: References the entire body contents of a request.
- Response – Header: Pulls specific header values out of a response.
To specify the data to be obtained from a response, in the empty URL bar, for example, we enter ‘/response’ and the options are displayed.
We select the desired one, in my case I selected Body Attribute. Then we click on the red tag and configure the rest of the options.
In Request we must specify which request we are referring to, we select it from the drop-down list. In Filter, which can be a JSONPath or XPath, we enter the data that we want to obtain from the response, which will be displayed in the Live Preview box.
In the following example in the GoRest project, we use the id obtained from the POST NewUser method response to send a GET UserById request. We pass the data as a request query:
And we configure the tag as follows:
In the following example in the CountryInfoService project, we take the ISO Code from the response of the CountryByName request and pass it to the FullCountryInfoByISOCode request as follows:
As in the previous case, we select the response that contains the data and in Filter we enter the corresponding XPath:
In this way, we can see that it is different from how data is handled between requests in Postman for example, although Insomnia also allows you to do it through environment variables.
Unit tests can be organized in Suites. They can be run individually or you can run the complete Suite.
Image 1 shows the organization of unit tests in Suites in the left panel.
Image 2 shows the unit tests within the Suite, related to the corresponding request, in the central panel.
And image 3 shows the results of the tests with the time consumed, in the panel located to the right of the workspace.
In the case of the project with SOAP it is the same procedure:
Inso CLI (Command Line Interface) for Insomnia is based on Node.js and the core Insomnia libraries. It allows you to use Insomnia functionality in terminal and CI/CD environments for automation. At this time, Inso CLI only works with design documents and does not request collections.
There are two ways to install Inso CLI:
Inso Run Test
In my case, I installed it using the first option. After installed, I tried with the commands as explained in the documentation, and this was the result of running the test suites of the GoREST project:
When running the inso run test command without specifying a document, we are prompted to select one from the list. After selecting the document or suite to test, we are asked to select the environment, as shown in the screenshot.
I did the same for the CountryInfoService project:
If a report type (dot, list, spec, min, and progress) is not specified, spec is used by default.
Inso Export Spec
This command extracts and exports the raw OpenAPI specification. The OpenAPI specification is the standard for documenting APIs, and OpenAPI 3.0 is the latest version. OpenAPI 3.0 offers several improvements, such as a simpler structure for defining APIs and more reusable components to reduce duplication.
With the –output <path> option the specification is saved to a file.
Export the specification loaded in the ‘DESIGN’ tab.
An OpenAPI document describes the public interface of the REST API and defines information such as name and description, the individual endpoints (paths), and how issuers are authenticated. One of the main benefits of using OpenAPI is for documentation; once you have an OpenAPI document that describes your API, it’s easy to generate reference documentation for it.
Inso Generate Config
This command generates a configuration from the API specification declared in DESIGN using openapi-2-kong. The command works similarly to generating a declarative configuration file or Kubernetes manifest from Insomnia. An example can be seen here.
Insomnia allows you to create a preformatted decK file when adding endpoints to the document, or you can take a document and generate a Kubernetes manifest.
Both options are also available in the Insomnia user interface.
Inso CLI is designed to run in a continuous integration (CI) environment, removes the need to interact with the tools through prompts, and provides exit codes to pass or fail the CI workflow. An example can be seen here.
Once entered into the dashboard we can manage the team and add members via email.
Once the work is synchronized, all team members can view the shared dashboard projects on Insomnia desktop.
A collaborator’s dashboard:
- Its paid version is the cheapest compared to Postman or SoapUI (see Pricing table).
- It allows you to manage the Cookies of the responses and send them in the requests automatically when necessary.
- It allows integration with GitHub in a simple way.
- It allows the handling of variables and data in a simpler way than alternative tools.
- It allows you to generate code snippets for more than 12 different languages from the requests.
- It also allows you to import an API swagger in the DESIGN tab from a yaml file or by manually entering the appropriate format.
- Environment variables can only be set in JSON format.
- The test scripts must be entered manually since it does not present snippets like Postman for example.
- Collaboration and teamwork are only available in the paid version.
- There’s Little documentation about requests for SOAP.
- Inso CLI does not work with collections.
- It’s only available for Desktop in English.
- Although it presents a dashboard on the web for teamwork management, requests and responses can only be managed from the desktop version.
The following table compares the various versions of Insomnia, Postman, and SoapUI.
|Insomnia||Postman||SoapUI / ReadyAPI|
|Individual||Free or Plus $5/user/month*||Free||Free|
|Teams||$10/user/month*||$15/user/month*|| $63.25/license/month* |
|Enterprise||n/a||$36/user/month*||$469.92/license/month* (API Performance)|
*Prices are expressed in US dollars.
Insomnia offers a trial version for 14 days allowing collaboration in teams of up to 5 members.
In the case of SoapUI/ReadyAPI, what is purchased is the license for different modules such as API Test or API Performance.
Although Insomnia has an interface very similar to Postman, as the work area is divided into 3 ‘tabs’ where different topics are dealt with (DESIGN/DEBUG/TEST), it makes it a more organized tool to work with.
The dashboard that it presents with the different workspace projects and other actions such as creating the documentation, are also user-friendly and help keep our projects organized.
In my opinion it has very similar features to Postman, not so with SoapUI. Compared to Postman, I found it to be a very versatile tool when it comes to working with data and variables. In the testing section, it would be better if some snippets are added to help.
Inso CLI allows an approach to test automation allowing to run the suites, although in my opinion it would be better being able to run the collections.
Finally, the integration with GitHub seems to me to be a plus to highlight since nowadays collaborative work on the network is essential.