Apidog CLI vs Redocly CLI: which API CLI should you use?

Both of these tools live in your terminal, both speak OpenAPI, and both show up when a team decides it wants a command-line workflow for its API specs. That’s where the overlap ends. They solve adjacent problems from opposite directions, and picking the wrong one means either fighting a linter that doesn’t run tests or reaching for a platform when all you wanted was a fast structural check.

This is a straight, command-level comparison of the Apidog CLI and the Redocly CLI. No strawmen. Redocly’s CLI is a genuinely good piece of open-source software, and you’ll see exactly where it shines before any verdict lands.

TL;DR verdict

They solve overlapping but different problems.

Redocly CLI (@redocly/cli, binary redocly) is a code-first OpenAPI specialist: lint with custom rulesets, bundle multi-file specs, split and join them, and build standalone HTML docs. It’s open source, config-driven, and terminal-native. If your spec is the source of truth and lives in git, this is governance you run from the command line.

Apidog CLI (apidog-cli, binary apidog) is the command-line surface of an all-in-one API platform. It imports and exports definitions against a project and runs API test scenarios in CI with JUnit and HTML reports. It earns its place when the same spec also needs to be mocked, tested, and documented in one workspace instead of stitched together from separate tools.

Pick Redocly CLI when you want a lightweight, open-source linter, bundler, and doc-builder you run purely from the terminal. Pick Apidog when you’d rather have one tool for the whole API lifecycle. They can also work side by side, and the last section explains how.

Two different philosophies

Redocly CLI is file-centric and code-first. The OpenAPI document on disk is the thing you act on. Every command, redocly lint, redocly bundle, redocly build-docs, takes a path to a file and does its job locally, with no account and no server in the loop. Behavior is shaped by a redocly.yaml config you check into the repo next to the spec. That model fits teams who treat their API description as source code: reviewed in pull requests, gated in CI, versioned like everything else. The OpenAPI Specification is the contract, and Redocly CLI is the toolchain that polices it.

Apidog is project-centric and platform-first. You design endpoints, build mock servers, and author test scenarios visually in the desktop or web app, and the CLI is the headless surface for a subset of that work. Most CLI commands operate against an Apidog project on the server, identified by a project ID and authenticated with an access token. The spec isn’t a loose file you lint in place; it’s imported into a living workspace where it can also be mocked, tested, and published as docs. One environment, many jobs.

Neither philosophy is wrong. They suit different teams. The honest distinction is this: Redocly gives you a focused, open-source CLI for spec governance, and Apidog gives you a CLI into a broader platform.

Command-by-command

Here’s the part that matters, mapped task by task. Every command below is real; nothing is invented.

A few of these rows deserve a plain-spoken note, because the difference is real and the article would be dishonest without it.

Linting is Redocly’s home turf, not Apidog’s. Redocly CLI lints OpenAPI, AsyncAPI, Arazzo, and Open-RPC against configurable rulesets, and you can author your own rules. Apidog validates a definition’s structure when you import it, but there is no apidog lint, no redocly.yaml-style config, and no way to write custom style-guide rules through the CLI. If your goal is a code-first style guide enforced in the terminal, Redocly is the tool. Apidog does not compete here, and saying otherwise would be wrong.

Split and join belong to Redocly. redocly split explodes one description into a multi-file structure, and redocly join (experimental) merges several files into one. Apidog has neither command. Its import resolves multi-file $refs into unified resources, and its export emits a single consolidated file, but that’s not the same as a standalone split/join utility you run on loose files.

Running tests and mocking belong to Apidog. Redocly CLI does not execute API tests and does not host a mock server; that’s outside its scope by design. Apidog runs test scenarios headlessly with apidog run and produces JUnit, HTML, JSON, and CLI reports for your pipeline, and mocking is a first-class feature of the platform (authored in the app, not driven from the CLI).

Both build HTML docs from the terminal. redocly build-docs produces a standalone Redoc HTML file. apidog export --format html writes an HTML docs file from your project. Different engines, same terminal outcome.

Real Redocly CLI commands

Install it globally, or skip the install and run it through npx:

npm install -g @redocly/cli@latest
# or, no global install:
npx @redocly/cli@latest lint openapi.yaml

Lint a spec. With a redocly.yaml present, this applies your chosen ruleset (minimal, recommended, recommended-strict, spec, or custom rules):

redocly lint openapi.yaml

If you only want plain structural validation, the kind the deprecated swagger-cli used to do, configure redocly.yaml with just the spec rule and run the same redocly lint. Redocly publishes a migration guide from swagger-cli because Redocly CLI is its named successor. The swagger-cli repo now carries a deprecation notice for the same reason; that old tool only ever validated and bundled, never linted with style rules.

Bundle a multi-file definition into one file, following every $ref:

redocly bundle openapi.yaml --output bundled.json

If you’re coming from swagger-cli, the flags map cleanly: -o/--outfile becomes --output, -t/--type becomes --ext (json, yaml, or yml), and -r/--dereference becomes -d/--dereferenced.

Build standalone HTML documentation with Redoc:

redocly build-docs openapi.yaml -o docs.html

Split a single description into a multi-file layout, the inverse of bundling:

redocly split openapi.yaml --outDir ./split-spec

For a wider look at how Redocly stacks up against other tooling in this category, the OpenAPI linter setup guide covers Spectral, Redocly, and Vacuum side by side, and the Redocly alternatives roundup covers the docs platform specifically.

Real Apidog CLI commands

Install the CLI and authenticate with a token from the app (avatar, then Account Settings, then API Access Token):

npm install -g apidog-cli@latest
apidog login --with-token <TOKEN>

The token lands in ~/.apidog/config.toml. Don’t print it or commit it.

Import a definition into a project. This validates the structure and ingests it, resolving multi-file $refs into unified resources:

apidog import --project 123456 --format openapi --file ./openapi.json

Import accepts more than OpenAPI: Postman, HAR, Insomnia, JMeter, WSDL, YApi, RAP2, apiDoc, Hoppscotch, Markdown, JSON Schema, and Apidog’s own format.

Export a single consolidated file, optionally upgrading the OpenAPI version. This is bundle plus an optional version bump in one step:

apidog export --project 123456 --format openapi --output ./openapi.json --oas-version 3.1

Export HTML docs straight from the project:

apidog export --project 123456 --format html --output ./docs.html

Run a test scenario in CI and emit reports your pipeline can read:

apidog run --project 123456 -t <testScenarioId> -e <environmentId> -r "cli,html,json,junit"

You can also run fully offline from an exported collection file, no project or token needed:

apidog run ./collection.apidog-cli.json

The full flag reference, including --out-dir, -n/--iteration-count, -d/--iteration-data, and --env-var, lives in the Apidog CLI complete guide. The official Apidog CLI documentation covers installation and every resource command. For a runner-to-runner CI comparison, see Apidog CLI vs Newman and Bruno CLI vs Apidog CLI.

When to choose Redocly CLI

Reach for Redocly CLI when the spec is your source of truth and you want to govern it as code.

You want a real linter with custom rules. Redocly’s lint command and its redocly.yaml config are the signature feature: pick a built-in ruleset or write your own, and enforce naming conventions, required fields, and house style on every commit. Nothing in Apidog’s CLI matches this. If terminal-native style governance is the job, Redocly is the answer.

You want open source with no account. The CLI runs entirely on your machine or CI runner. No login, no token, no server call for lint, bundle, split, or build-docs. For air-gapped environments or strict data-handling rules, that’s a hard requirement Redocly meets and a platform CLI generally doesn’t.

You want a lightweight, focused toolchain. If all you need is lint, bundle, split, join, and HTML docs from the terminal, Redocly does exactly that and nothing more. You can install it or run it through npx with zero setup. The full command set is in the Redocly CLI docs and the npm package page.

When to choose Apidog

Reach for Apidog when the spec is one part of a larger lifecycle you’d rather not assemble from separate tools.

You want design, mock, test, and docs in one place. The CLI imports your spec, exports a clean consolidated file at the OpenAPI version you choose, and runs test scenarios in CI. The same project also gives you visual design, a mock server, and published documentation, all sharing one definition. You stop wiring together a linter, a mock tool, a test runner, and a docs generator.

You want test execution in your pipeline with usable reports. apidog run produces JUnit XML for your CI dashboard, plus HTML and JSON artifacts, and exits non-zero when a test fails. Redocly doesn’t run tests at all, so if CI test gating is on your list, this is where Apidog fits. The patterns in OpenAPI validation in CI pair naturally with a test run on the same pipeline.

You want one source of truth for a whole team. Resources live in an Apidog project that designers, testers, and writers all work from. The CLI is the automation surface over that shared workspace, which suits teams who’d rather collaborate in a platform than pass spec files around.

Download Apidog to follow along. It’s free to start, no credit card required.

They can be complementary

This isn’t strictly either-or, and pretending it is would miss the most practical setup.

A strong workflow runs Redocly CLI (or Spectral) as the lint gate in CI, enforcing your style guide on every pull request, and uses Apidog for design, mocking, test execution, and published docs. Lint where lint is best, with open-source rulesets in the terminal. Mock, test, and document where a platform is best. The spec flows between them: lint the file in CI, import it into Apidog for everything downstream.

That combination plays to each tool’s actual strength instead of forcing one to do the other’s job.

FAQ

Does Apidog CLI have a lint command with custom rules like Redocly?

No. Apidog validates a definition’s structure when you import it, but there’s no apidog lint command and no way to author custom style-guide rules through the CLI. For configurable, code-first linting, use Redocly CLI or Spectral.

Can Redocly CLI run API tests in CI?

No. Redocly CLI lints, bundles, splits, joins, and builds docs. It doesn’t execute API tests and doesn’t host a mock server. For headless test runs with JUnit and HTML reports, use apidog run.

Is Apidog open source like Redocly CLI?

No. Redocly CLI and Spectral are open source. Apidog is freemium: the CLI is free to install from npm, but it operates against an Apidog account and project rather than as fully open-source software.

I used swagger-cli for validate and bundle. What should I move to?

Both tools cover it. Redocly CLI is swagger-cli’s named successor, with redocly lint (configure the spec rule for plain validation) and redocly bundle. Apidog covers the same ground through apidog import (validate) and apidog export (bundle, with an optional OpenAPI version bump), and adds mocking, testing, and docs in the same workspace.