How to Migrate From inso (Insomnia CLI) to Apidog CLI

If you run API tests with inso, Kong’s Insomnia CLI, this migration guide shows how to move to Apidog CLI with minimal CI churn. You’ll export specs and collections from Insomnia, import them into Apidog, rebuild test suites as Apidog test scenarios, and replace inso run commands with apidog run.

Try Apidog today

Why migrate from inso to Apidog CLI?

inso is a solid CLI for running requests, Spectral linting, and unit tests from a .insomnia directory created by Insomnia Git Sync.

Teams usually consider moving for three reasons:

• Insomnia app login requirements. Insomnia 8 introduced a required cloud account/login flow, which was disruptive for teams expecting a local-first API client.
• Data-loss or migration issues. If you are recovering data, start with these guides: recovering and exporting Insomnia data and Insomnia 8 data-loss recovery and migration.
• Tool consolidation. With inso, you may still need separate tools for mocks, docs, linting, and test orchestration. Apidog combines API design, debugging, testing, mocking, and documentation in one platform, with CLI support for running tests.

For broader app-level comparisons, see Apidog vs Insomnia and choosing between Insomnia and Apidog.

Before you start: what migrates?

Set expectations before changing your CI scripts.

Asset in Insomnia	Moves to Apidog?	How
OpenAPI / design documents	Yes	Export to YAML/JSON, then import into Apidog
Request collections	Yes	Export from Insomnia, then import
Environments and variables	Yes	Recreate as Apidog environments
Unit test suites using inso run test	Partially	Rebuild as Apidog test scenarios
Spectral lint config using inso lint spec	No 1:1 equivalent	Keep Spectral in CI if you depend on custom rules

Important: inso lint spec runs Spectral, Stoplight’s OpenAPI linter. Apidog CLI does not provide a standalone spec linter, style-guide, split, join, or bundle command. Apidog validates specs during import, but if your pipeline depends on custom Spectral rulesets, keep Spectral as a separate CI step.

Step 1: export specs and collections from Insomnia

Export your OpenAPI design document with inso:

# Export an OpenAPI design document to YAML
inso export spec "My API Design" --output my-api.yaml

If inso cannot find your workspace data, point it to the correct source directory:

inso export spec "My API Design" \
  --workingDir ./design \
  --output my-api.yaml

For request collections or anything that does not export cleanly through inso, use the Insomnia app:

1. Open Insomnia.
2. Select the workspace.
3. Use Export.
4. Save both:
   • the OpenAPI design document
   • the Insomnia collection export

If you are recovering from a broken migration or login issue, use the Insomnia export and recovery walkthrough first.

Step 2: import the exported files into Apidog

Open Apidog, create a project, and import the YAML or JSON file exported from Insomnia.

Apidog reads OpenAPI natively, so your endpoints, schemas, and examples become editable project resources that you can test, mock, and document.

You can also automate setup from the CLI. This is useful when migrating multiple projects or standardizing team setup. Apidog CLI supports working with OpenAPI resources and project assets from the terminal, with authentication through login or access token.

Start with:

• Apidog CLI installation guide
• Apidog CLI complete guide

During import, Apidog validates the spec. Treat this as structural validation, not as a replacement for configurable Spectral linting.

Step 3: replace inso commands with apidog run

Use this table to update your local scripts and CI jobs.

Task	Before: inso	After: Apidog CLI
Run a unit test suite	inso run test "Smoke Suite" --env "Staging"	apidog run --test-scenario "Smoke Suite" -e staging
Run a collection	inso run collection "Checkout Flow" --env "Staging"	apidog run "Checkout Flow" -e staging
Run a named script	inso script ci-smoke --env <env-id>	apidog run -e <env-id>, or wrap it in your own CI/npm/make script
Lint an OpenAPI spec	inso lint spec "My API Design"	No 1:1 command; Apidog validates on import
Export a spec to file	inso export spec "My API Design" --output api.yaml	Use Apidog import/export workflows; this is not usually a test runtime step

Key migration notes:

• Environments: inso uses --env. Apidog supports -e / --env. Recreate your Insomnia environments in Apidog before updating CI.
• Unit test suites: inso run test maps to Apidog test scenarios. Rebuild the suite once in Apidog as ordered requests plus assertions.
• Scripts: If you used inso script as indirection, replace it with a direct apidog run command or wrap Apidog CLI in your own shell/npm/make script.

For a deeper command comparison, see Apidog CLI vs inso. If you also use Newman or Postman CLI, see Apidog CLI vs Newman and Apidog CLI vs Postman CLI.

Step 4: configure reporters

A typical inso CI setup may output CLI logs or JUnit reports. With Apidog CLI, choose reporters such as cli, html, and json.

Example:

# Run a scenario and generate console + HTML output
apidog run --test-scenario "Smoke Suite" -e staging -r cli,html

Use:

• cli for live CI logs
• json when another tool parses test output
• html when humans review reports
• --upload-report when you want reports uploaded to Apidog

Example with JSON and cloud upload:

apidog run --test-scenario "Smoke Suite" \
  -e staging \
  -r cli,json \
  --upload-report

See the Apidog CLI test reports guide for format details.

Step 5: migrate data-driven tests

If your Insomnia tests used external data, move that logic into Apidog data-driven testing.

Run a scenario once per CSV or JSON row with -d:

apidog run --test-scenario "Login Matrix" \
  -e staging \
  -d ./users.csv \
  -r cli,json

Use this pattern for login matrices, role-based permission checks, boundary-value tests, and repeated workflow tests.

The data-driven testing guide covers dataset formats and variable binding.

Step 6: update your CI pipeline

Your current CI step may look like this:

# Before: inso in CI
inso run test "Smoke Suite" --env "CI" --reporter junit

Replace it with:

# After: Apidog CLI in CI
apidog run --test-scenario "Smoke Suite" \
  -e ci \
  -r cli,json \
  --upload-report

Then configure authentication:

1. Create or obtain an Apidog access token.
2. Store it as a CI secret.
3. Use the token in your CI job before running apidog run.

For copy-paste CI examples, see:

• Apidog CLI CI/CD pipeline guide
• Apidog CLI GitHub Actions guide
• Apidog CLI authentication

Keep Spectral if linting is a release gate

If your inso workflow used custom Spectral rules, keep that step. Do not replace it with apidog run.

A practical hybrid pipeline looks like this:

# Lint with Spectral
npx @stoplight/spectral-cli lint my-api.yaml

# Run tests with Apidog CLI
apidog run --test-scenario "Smoke Suite" \
  -e ci \
  -r cli,json

This keeps your OpenAPI style and governance checks intact while moving runtime API testing to Apidog.

inso vs Apidog CLI at a glance

Capability	inso / Insomnia CLI	Apidog CLI
Run collections / suites	Yes	Yes
Environment selection	--env	-e / --env
OpenAPI linting	Yes, via Spectral	No standalone linter; validates on import
Data-driven testing	Limited	Yes, with -d for CSV/JSON
Report formats	CLI, JUnit	CLI, HTML, JSON, cloud upload
Resource-as-code workflow	Reads .insomnia directory	Endpoints, schemas, environments, branches, merge requests
Platform scope	Insomnia plus external tools	Design, mock, docs, and test in one platform
Cloud account requirement for app	Yes, Insomnia 8+	Apidog account; local-friendly workflow

FAQ

Will my Insomnia OpenAPI spec import into Apidog without edits?

Usually yes. Apidog reads OpenAPI natively and validates during import. If validation fails, fix the structural issue in the spec before wiring it into CI.

Does Apidog CLI have a lint command like inso lint spec?

No. Apidog validates specs on import, but it does not provide a standalone CLI linter or style-guide command. If you rely on custom Spectral rulesets, keep Spectral in your pipeline next to apidog run.

For comparison with a CLI that does include linting, see Apidog CLI vs Redocly CLI.

Can I run Apidog CLI in CI like I ran inso?

Yes. Replace the command, authenticate with an access token stored as a CI secret, and choose reporters such as cli, json, or html.

See the CI/CD guide for full workflow examples.

What happens to my Insomnia unit test suites?

Rebuild them as Apidog test scenarios. The structure is similar: ordered requests plus assertions. After the one-time rebuild, run them with apidog run.

I’m migrating because of an Insomnia data-loss incident. Where should I start?

Recover and export your data first with the recovery and export guide. Then import the cleaned OpenAPI or collection export into Apidog.

Wrap-up

Migrating from inso to Apidog CLI is mostly a command and workflow translation:

1. Export specs and collections from Insomnia.
2. Import them into Apidog.
3. Recreate environments.
4. Rebuild unit test suites as Apidog test scenarios.
5. Replace inso run test and inso run collection with apidog run.
6. Use -e / --env for environments.
7. Configure cli, html, or json reporters.
8. Keep Spectral if custom OpenAPI linting is required.

Ready to try it? Download Apidog and run your first apidog run against the spec you exported.