Best Insomnia CLI (inso) Alternatives for API Testing in CI

If you run Insomnia in CI, you probably use inso: the command-line companion to Kong’s open-source Insomnia API client. From a terminal, it can run test suites, run request collections, lint OpenAPI specs with Spectral, and export specs. That is enough for many teams, but the workflow can become brittle once you depend on it in CI.

Try Apidog today

This guide breaks down what inso does, where it creates friction, and which inso alternatives fit different use cases. The right Insomnia CLI alternative depends on what you currently use inso for: request execution, API testing, OpenAPI linting, or a broader API platform workflow.

What inso does

inso reads API data from either:

• a .insomnia directory created by Insomnia Git Sync
• the Insomnia desktop app data directory

You run suites and specs by name:

inso run test "My API Test Suite" --env "Staging"
inso run collection "Smoke Tests" --env "Staging"
inso lint spec "Petstore Design Doc"
inso export spec "Petstore Design Doc" --output openapi.yaml

Installation options include Homebrew, Docker, and downloadable binaries:

brew install inso
docker pull kong/inso:latest

One important strength: inso lint spec uses Spectral, the Stoplight OpenAPI linter. If OpenAPI linting is your primary use case, do not replace inso with a request runner unless you also add a dedicated linting tool.

Where inso creates friction

Teams usually look for an alternative to inso for these reasons:

• Insomnia database coupling: test definitions live in .insomnia or the desktop app data folder.
• Name-based references: CI commands reference suites and specs by display name, so renaming something in the GUI can break automation.
• Cloud account concerns: Insomnia 8 introduced a required cloud login in 2023, which caused backlash and migration concerns for some teams.
• Mixed responsibilities: inso combines request execution and OpenAPI linting. If you only need one, a focused tool may be simpler.

Alternatives at a glance

Tool	Type	Source format	Data-driven	Reporters	Open source	Best for
Apidog CLI	Full platform runner	Apidog project / OpenAPI import	Yes (-d CSV/JSON)	CLI, HTML, JSON	No, free tier available	One platform for design, mock, docs, and testing
Newman	Postman collection runner	Postman collection JSON	Yes (-d CSV/JSON)	CLI, HTML, JSON	Yes	Existing Postman collections
Hoppscotch CLI	OSS collection runner	Hoppscotch collection JSON / cloud ID	Yes, iteration data CSV	CLI, JUnit XML	Yes	Free, self-hostable OSS pipelines
Step CI	Declarative API tester	YAML / JSON workflow files	Limited	CLI, JUnit	Yes	Config-as-code API tests
Hurl	Plain-text HTTP runner	.hurl text files	Via variables	CLI, JUnit, HTML	Yes	Lightweight HTTP assertions

1. Apidog CLI: full API platform runner

Apidog is an all-in-one API platform for design, debugging, testing, mocking, and documentation. The Apidog CLI brings test execution into your terminal and CI/CD pipeline.

Use apidog run to execute test scenarios and collections:

apidog run --access-token <token> -t <scenario-id> -e <env-id>
apidog run -t <scenario-id> -d ./users.csv -r html,cli
apidog run -t <scenario-id> --upload-report

Useful options:

• -t: run a test scenario
• -e: select an environment
• -d: run data-driven tests with CSV or JSON
• -r: generate reports, such as cli, html, or json
• --upload-report: upload cloud test reports

Apidog CLI also supports API resource workflows from the terminal, including OpenAPI import and management of endpoints, schemas, environments, branches, and merge requests.

That makes it a better fit when you want a broader API workflow instead of only a request runner.

Important limitation: Apidog CLI does not provide a standalone OpenAPI linter, style-guide checker, split, join, or bundle command. It validates specs on import, but it does not replace inso lint spec powered by Spectral.

Pros

• One platform for design, mock, docs, and testing
• Data-driven runs with -d
• CLI, HTML, and JSON reporters
• Environment support
• Cloud report upload
• API resources and branches managed from the CLI

Cons

• No standalone OpenAPI linting like Spectral
• Free tier available, but not fully open source

Useful references:

• Apidog CLI complete guide
• Apidog CLI vs Newman
• Apidog CLI vs Postman CLI
• Apidog CLI GitHub Actions guide

2. Newman: Postman collection runner

Newman is Postman’s open-source CLI runner. If your team already maintains Postman collections, Newman is the most direct inso CLI alternative for request execution.

newman run collection.json -e staging.json -d data.csv -r cli,html,json

Common options:

• collection.json: exported Postman collection
• -e: environment file
• -d: CSV or JSON data file
• -r: reporters

Pros

• Runs existing Postman collections
• Open source
• Large community
• Many CI examples
• Strong reporter ecosystem

Cons

• Tied to Postman collection format
• No OpenAPI linting
• Collection management still usually happens in Postman

For a direct comparison, see Apidog CLI vs Newman.

3. Hoppscotch CLI: open-source and self-hostable

Hoppscotch is an open-source API ecosystem with web, desktop, CLI, and self-hosted options. Its CLI package, @hoppscotch/cli, runs collections in CI.

Install it with npm:

npm i -g @hoppscotch/cli

Run local or hosted collections:

hopp test ./collection.json -e ./env.json -d 100
hopp test <collection-id> --token <pat> --server https://hoppscotch.example.com
hopp test ./collection.json --reporter-junit ./report.xml

hopp test can:

• recursively run every request in a collection
• execute pre-request scripts
• execute test scripts with pw.test() and pw.expect()
• validate responses
• exit non-zero on failed assertions
• emit JUnit XML reports

Useful flags include:

• -e: environment file
• -d: delay
• --token: personal access token
• --server: self-hosted Hoppscotch server
• --reporter-junit: JUnit report output
• --iteration-count: number of iterations
• --iteration-data: data file for iterations

Note: current versions require Node.js v22 or newer. Node 20 users need CLI v0.26.0.

Pros

• Fully open source
• Self-hostable
• No required vendor account
• JUnit reporting
• Data-driven iterations
• Supports cloud or self-hosted collection references

Cons

• Node v22+ requirement may affect older CI images
• Smaller ecosystem than Newman
• No OpenAPI linting

More comparisons:

• Hoppscotch alternatives
• Postman vs Hoppscotch
• Apidog CLI vs Hoppscotch CLI

4. Step CI: declarative API tests in your repo

Step CI uses YAML or JSON workflow files instead of GUI-managed collections. This is useful if you want API tests to live beside application code and be reviewed in pull requests.

Example workflow:

version: "1.1"
name: Status check
tests:
  health:
    steps:
      - name: GET health
        http:
          url: https://api.example.com/health
          method: GET
          check:
            status: 200

This avoids inso’s name-based references. The test definition is the file, and the file path becomes the stable reference.

Pros

• Tests are plain files in your repo
• Easy to review in pull requests
• No app database
• No GUI dependency
• Good fit for config-as-code workflows

Cons

• Less interactive for ad-hoc debugging
• Smaller community
• More manual authoring
• Data-driven support is more limited than Newman or Apidog

Step CI is a strong Insomnia CLI replacement when your main goal is to move test definitions into version-controlled files.

5. Hurl: plain-text HTTP tests

Hurl is a lightweight HTTP runner. You write requests and assertions in .hurl files.

GET https://api.example.com/users/1
HTTP 200
[Asserts]
jsonpath "$.id" == 1
jsonpath "$.name" exists

Run it with:

hurl --test users.hurl

Hurl supports:

• chained requests
• captured variables
• HTTP assertions
• JUnit reports
• HTML reports

It works well for smoke tests, health checks, and simple contract checks.

Pros

• Simple plain-text format
• Easy to version-control
• No GUI
• No account
• Small CI footprint
• Chained requests with variables

Cons

• Complex scenarios can become verbose
• No collection GUI
• Less approachable for non-CLI users
• No OpenAPI linting

How to choose

Pick based on what you currently use inso for.

Use Apidog CLI if you want one API platform

Choose Apidog CLI if you want testing, design, mocks, docs, environments, reports, and resource management in one workflow.

apidog run -t <scenario-id> -e <env-id> -d ./data.csv -r cli,html,json

Best fit:

• platform-based API development
• CI test execution
• data-driven API tests
• cloud reports
• teams that want more than a standalone runner

Use Newman if you already have Postman collections

Choose Newman if your existing source of truth is Postman.

newman run collection.json -e staging.json -d data.csv

Best fit:

• existing Postman users
• open-source CLI collection running
• teams with mature Postman test suites

Use Hoppscotch CLI if you want open source and self-hosting

Choose Hoppscotch CLI if you want an open-source collection runner with self-hosting support.

hopp test ./collection.json -e ./env.json --reporter-junit ./report.xml

Best fit:

• OSS-first teams
• self-hosted API tooling
• JUnit-based CI pipelines

Use Step CI if you want declarative tests

Choose Step CI if you want API tests as YAML or JSON files in your repo.

Best fit:

• config-as-code workflows
• pull-request review of API tests
• teams avoiding GUI-managed test state

Use Hurl if you want minimal HTTP checks

Choose Hurl for lightweight smoke tests and plain-text assertions.

hurl --test users.hurl

Best fit:

• simple API health checks
• fast CI smoke tests
• minimal dependencies

Keep inso or add Spectral if OpenAPI linting is the priority

If your main command is:

inso lint spec "Petstore Design Doc"

be careful when switching. Most tools above do not replace Spectral-based OpenAPI linting.

Options:

• keep inso for linting
• run Spectral directly
• pair your chosen test runner with a dedicated OpenAPI linting CLI

Migration resources

If you are moving away from the broader Insomnia ecosystem, these guides may help:

• Apidog vs Insomnia
• Best Insomnia app alternatives
• Insomnia data loss and migration
• Migrate from inso to Apidog CLI