DEV Community

Cover image for Best Lightweight CLI Tools for API Mocking
Hassann
Hassann

Posted on • Originally published at apidog.com

Best Lightweight CLI Tools for API Mocking

You need a fake API to develop against in the next thirty seconds—not a hosted service, Docker Compose stack, or GUI workflow. Just run a command, point it at a file, and serve responses on localhost.

Try Apidog today

A lightweight mock server lets your frontend, integration tests, or CI job call realistic endpoints while the real backend is still under construction. The fastest options run as a single binary or an npx package, start in under a second, and require almost no configuration. Heavier JVM-based tools are useful when you need advanced request matching, delays, failures, or stateful test scenarios.

This guide ranks six CLI mock tools by setup friction: first the tools you can run without installing anything, then standalone JVM servers, and finally the integrated Apidog CLI workflow. Every command below is based on each tool's official documentation. For GUI and hosted alternatives, see the best API mock tools.

What makes a CLI mock tool “lightweight”

“Lightweight” is about footprint and friction, not only feature count. Evaluate each tool using four practical criteria:

  • Install size and runtime: An npx-based Node package usually needs only Node.js. A standalone JVM server is typically a 20MB+ JAR and requires Java.
  • Startup speed: The server should be ready before you switch back to your editor. Node-based tools generally cold-start in well under a second.
  • Time to first response: The ideal flow is one input file plus one command.
  • Terminal-first workflow: No account, dashboard, or GUI is required. The server should fit naturally into shell scripts and CI jobs.

Prism, Mockoon CLI, and json-server are the quickest options because you can run them directly with npx.

Prism (Stoplight)

Use Prism when you already have an OpenAPI definition and want a mock that follows the contract.

npx @stoplight/prism-cli mock ./openapi.yaml
Enter fullscreen mode Exit fullscreen mode

Prism starts on http://127.0.0.1:4010 and exposes every operation in your specification.

What Prism does

  • Reads OpenAPI paths, response examples, and schemas.
  • Returns defined response examples when available.
  • Generates schema-valid random responses when examples are missing.
  • Validates incoming requests against the specification.
  • Returns 422 for malformed requests instead of silently accepting them.

For a global install:

npm install -g @stoplight/prism-cli
prism mock ./openapi.yaml
Enter fullscreen mode Exit fullscreen mode

Best for: Spec-first teams that need the mock to stay aligned with the API contract. Prism is Apache-2.0 licensed and supports OpenAPI 3.1, 3.0, 2.0, and Postman collections.

Honest limits: Prism is stateless. A POST request does not persist data, so it cannot simulate create-then-read flows without additional tooling. Its generated responses are only as useful as your schemas and examples. For contract-accurate mocking, that is usually the intended trade-off. It also fits well into a REST API mocking tools workflow.

Mockoon CLI

Mockoon CLI runs a mock API from either:

  • A Mockoon environment file exported from the free desktop app.
  • An OpenAPI JSON or YAML file.

Start an environment file with:

npx @mockoon/cli start --data ./mockoon-env.json --port 3000
Enter fullscreen mode Exit fullscreen mode

The CLI serves the configured routes immediately.

Typical workflow

  1. Build routes visually in Mockoon Desktop.
  2. Export or save the environment definition.
  3. Run the environment headlessly in local development or CI.

You can also point --data directly to an OpenAPI file. If an environment file uses an older Mockoon format, the CLI migrates it in memory without changing the source file.

For a global install:

npm install -g @mockoon/cli
mockoon-cli start --data ./mockoon-env.json --port 3000
Enter fullscreen mode Exit fullscreen mode

Best for: Teams that want to design mocks in a GUI but run them headlessly. Mockoon is MIT-licensed and provides an official Docker image.

Honest limits: The richest route definitions are typically created in the desktop app. Hand-editing a Mockoon JSON environment can be more cumbersome than maintaining a simple OpenAPI or JSON file. If you want a file-first workflow with no companion app, use Prism or json-server.

json-server

Use json-server when you do not have an API specification yet and need a working REST API immediately.

Create a data file:

echo '{ "posts": [{ "id": 1, "title": "hello" }] }' > db.json
Enter fullscreen mode Exit fullscreen mode

Start the server:

npx json-server db.json
Enter fullscreen mode Exit fullscreen mode

You now have a REST endpoint at:

http://localhost:3000/posts
Enter fullscreen mode Exit fullscreen mode

What you get automatically

For a posts collection, json-server generates REST operations including:

  • GET /posts
  • GET /posts/:id
  • POST /posts
  • PUT /posts/:id
  • PATCH /posts/:id
  • DELETE /posts/:id

Unlike stateless spec mockers, json-server persists changes back to db.json. A POST /posts adds a record, which makes it useful for basic stateful frontend development.

It also supports filtering, sorting, and pagination through query parameters. The current 1.x line watches the data file and reloads when it changes.

Install globally if needed:

npm install -g json-server
json-server db.json
Enter fullscreen mode Exit fullscreen mode

Best for: Frontend developers who need a working REST backend before the real API exists. It is MIT-licensed and is one of the lightweight mock server options for a RESTful API that requires no specification.

Honest limits: json-server assumes a resource-oriented REST shape. It is not ideal for custom RPC-like routes, strict contract validation, or detailed header and body matching.

MockServer

MockServer is the option to choose when request matching matters more than startup speed.

Instead of serving an entire spec or generating CRUD routes from data, MockServer lets you define explicit expectations:

  • Match by HTTP method.
  • Match by path.
  • Match headers, query parameters, or request bodies.
  • Return exact responses.
  • Add delays and failures to test timeout and error handling.

Start the standalone server:

java -jar mockserver-netty-5.15.0-no-dependencies.jar -p 1080
Enter fullscreen mode Exit fullscreen mode

MockServer listens on port 1080. Configure expectations through its REST API or programmatically.

For Node.js projects, use the official wrapper:

npm install mockserver-node
Enter fullscreen mode Exit fullscreen mode
const mockserver = require('mockserver-node');

mockserver.start_mockserver({
  serverPort: 1080,
});
Enter fullscreen mode Exit fullscreen mode

Best for: Integration tests that need fine-grained assertions about requests and fully controlled responses. MockServer is Apache-2.0 licensed and supports HTTP, HTTPS, and more on a single port.

Honest limits: It is JVM-based, so it is heavier and slower to start than the Node options. Expectation setup is also more verbose than pointing Prism at an OpenAPI file. If you only need to serve a specification, this is usually overkill. See MockServer alternatives for trade-offs.

WireMock (standalone)

WireMock is another established JVM mock server, widely used in Java and JVM testing workflows. Its standalone JAR uses the same engine that can be embedded in JUnit tests, so local mocks can be shared with automated test suites.

Start WireMock:

java -jar wiremock-standalone.jar --port 8080
Enter fullscreen mode Exit fullscreen mode

WireMock listens on port 8080.

Configure stubs

WireMock can load stub mappings from a mappings/ directory or accept them through its JSON API. It can also record real HTTP traffic and replay it as stubs, which is useful when mocking third-party APIs you do not control.

There is also an official wiremock/wiremock Docker image for CI environments.

Best for: JVM teams that want one mock engine for local development and tests, plus record-and-replay support. WireMock is Apache-2.0 licensed.

Honest limits: Like MockServer, WireMock requires Java and starts more slowly than Node-based tools. Its JSON stub mappings are powerful, but they require more setup than a single data file. If you are coming from JavaScript, see this Mock Service Worker (MSW) alternative comparison for browser-first context.

Apidog CLI

The previous tools each solve a specific part of API mocking. Apidog takes an integrated approach: API design, mocks, tests, and documentation live in one project, while the Apidog CLI lets you work with that project from the terminal.

Apidog is not open source. It is a commercial product with a free tier. The free tier and CLI provide an alternative to combining separate tools for specifications, mock servers, test execution, and documentation.

Apidog automatically generates smart mocks from defined endpoints. Responses follow schema field types and naming, so a phone field can return a plausible phone number instead of an arbitrary string. For request-specific behavior, add mock expectations and manage them from the CLI.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog mock --help
Enter fullscreen mode Exit fullscreen mode

The mock command group works with project mock expectations from scripts and CI. Apidog also includes command groups for endpoints, schemas, environments, and test runs.

CLI output is structured JSON and includes an agentHints.nextSteps field, making it usable in automated workflows and by AI agents. See the Apidog CLI complete guide for the full command surface.

Best for: Teams that want mocks, API specifications, and tests in one project instead of maintaining separate tools. Download Apidog to try the built-in mock server and CLI with your own project.

Honest limits: Apidog is a platform rather than a single-purpose binary, so it requires a project and login where json-server requires neither. For a throwaway one-file mock, a smaller tool is usually better. If you already design APIs in Apidog, the mock workflow is already part of the project.

How to choose

Choose based on what you already have:

  • You have an OpenAPI spec: Use Prism or Mockoon CLI.
  • You have no spec and need CRUD quickly: Use json-server.
  • You need exact request matching: Use MockServer or WireMock.
  • You want mock, design, tests, and docs in one workflow: Use Apidog.
Tool Best for Install Open source? Notes
Prism Serving an OpenAPI spec as a mock npx @stoplight/prism-cli Yes (Apache-2.0) Contract-accurate, stateless, port 4010
Mockoon CLI GUI-built mocks run headlessly npx @mockoon/cli Yes (MIT) Reads environment files or OpenAPI, Docker image
json-server Instant REST API from JSON npx json-server Yes (MIT) Stateful CRUD, no spec needed, port 3000
MockServer Precise request matching java -jar mockserver-netty-*.jar Yes (Apache-2.0) JVM, npm wrapper available, port 1080
WireMock Shared JVM development and test engine java -jar wiremock-standalone.jar Yes (Apache-2.0) Record-and-replay, Docker image, port 8080
Apidog CLI Mock, spec, and tests in one project npm install -g apidog-cli No (free tier) Auto smart mock and managed expectations

The practical rule is simple: use npx tools for speed, JVM servers for matching depth, and Apidog when you want one workflow instead of several. If you are still deciding whether mocking is worth the effort, review these API mocking use cases.

Wrapping up

Choose the smallest tool that accepts the input you already have:

  • Send an OpenAPI spec to Prism or Mockoon CLI.
  • Send a blank slate and JSON data to json-server.
  • Use MockServer or WireMock for strict matching and controlled failure scenarios.
  • Use Apidog when you want mocks next to API design and tests.

All six tools run from the terminal and fit into CI jobs. Start with the lowest-friction option, then add complexity only when your use case requires it. To try the integrated workflow, download Apidog and generate a mock server from an API design.

Top comments (0)