Best Lightweight CLI Tools for API Mocking

You need a fake API to develop against, and you need it in the next thirty seconds. Not a hosted service, not a Docker Compose stack, not a GUI to click through. Just a command that reads a file and starts serving responses on localhost.

That’s what a lightweight mock server does. You point it at an OpenAPI spec or a small data file, run one command, and get realistic endpoints your frontend or tests can hit while the real backend is still being built. The best ones ship as a single binary or an npx-able package, start in under a second, and need almost no config. Some of the heavier options here run on the JVM and do far more; they earn their place when you need advanced request matching or stateful behavior.

This guide ranks six CLI mockers by how little they ask of you. It leads with the ones you can run without installing anything, then covers the standalone JVM servers, and closes with the integrated route through the Apidog CLI. Every install command and mock command below was checked against each tool’s official docs. If you want the broader field beyond the command line, the roundup of the best API mock tools covers GUI and hosted options too.

What makes a CLI mock tool “lightweight”

Lightweight is about footprint and friction, not feature count. When you’re comparing these tools, weigh four things:

• Install size and runtime. A pure-Node package you can npx weighs a few megabytes. A standalone JVM server is a 20MB+ jar that needs a Java runtime. Both are valid; they sit at different ends of this list.
• Startup speed. A good mock server is running before you’ve switched back to your editor. Node-based tools cold-start in well under a second.
• Config to first response. Can you go from zero to a live endpoint with one file and one command? The lightest tools say yes.
• Terminal-first. No account, no dashboard, no GUI step in the loop. The tool reads a file and serves it, and it fits in a shell script or CI job.

The tools are ordered smallest-and-fastest first. Prism, Mockoon CLI, and json-server are the ones you can run with npx and no global install.

Prism (Stoplight)

Prism turns an OpenAPI file into a live mock server with one command. If you already have a spec, this is the lowest-effort mock on the list; it reads your paths, examples, and schemas and serves responses that match them.

npx @stoplight/prism-cli mock ./openapi.yaml

That starts a server on http://127.0.0.1:4010 with every operation in your spec wired up. Prism returns the example you defined for a response, or generates a valid random one from the schema if you didn’t. It also validates incoming requests against the spec, so a malformed call gets a proper 422 instead of a silent pass. For a global install, use npm install -g @stoplight/prism-cli and drop the npx.

Best for: spec-first teams who want the mock to stay honest to the 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 doesn’t persist anything, so it won’t fake a create-then-read flow. Its mock is only as good as your spec; thin examples mean thin responses. For contract-accurate mocking that’s exactly the point, and it pairs well with the REST API mocking tools workflow.

Mockoon CLI

Mockoon CLI runs a mock API from a data file, either one you exported from the free Mockoon desktop app or a plain OpenAPI spec. The desktop app lets you build routes visually; the CLI runs that same environment headless in CI or on a server.

npx @mockoon/cli start --data ./mockoon-env.json --port 3000

Point --data at a Mockoon environment file or an OpenAPI JSON/YAML file and it serves immediately. If the data file came from an older Mockoon version, the CLI migrates it in memory without touching the original. Install it globally with npm install -g @mockoon/cli if you prefer a persistent mockoon-cli command.

Best for: teams who want to design mocks in a GUI but run them headless. It’s MIT-licensed and has an official Docker image for deployments.

Honest limits: the richest routes are built in the desktop app, so hand-editing the JSON environment file is fiddly. If you don’t want a companion app at all, Prism or json-server keep everything in a single file you write by hand.

json-server

json-server is the fastest way to fake a REST API when you don’t have a spec yet. You write a plain JSON file describing your data, and it generates a full REST API around it, complete with GET, POST, PUT, PATCH, and DELETE.

echo '{ "posts": [{ "id": 1, "title": "hello" }] }' > db.json
npx json-server db.json

That serves http://localhost:3000/posts with real CRUD. A POST to /posts actually adds a record and writes it back to db.json, so you get stateful behavior for free, which Prism and WireMock won’t give you out of the box. You also get filtering, sorting, and pagination via query params. The current 1.x line watches the file and reloads on change by default; install globally with npm install -g json-server if you want it always on your PATH.

Best for: frontend developers who need a working REST backend in one minute, before the real API exists. It’s MIT-licensed and one of the lightweight mock server options for a RESTful API that needs zero spec.

Honest limits: it assumes a resource-style REST shape. Deeply custom routes, non-REST endpoints, or strict header matching fall outside what it does cleanly. It’s a prototyping tool, not a contract validator.

MockServer

MockServer is the heavyweight for precise request matching. Where the tools above serve a spec or a data file, MockServer lets you define expectations: match a request by method, path, header, query, or body, then return exactly the response you want, including delays and failures for testing timeouts and error handling.

java -jar mockserver-netty-5.15.0-no-dependencies.jar -p 1080

That starts MockServer on port 1080. You then send expectations to its REST API to configure behavior, or drive it programmatically. Node users can skip the raw jar and use the official wrapper:

npm install mockserver-node

const mockserver = require('mockserver-node');
mockserver.start_mockserver({ serverPort: 1080 });

Best for: integration tests that need fine-grained control over what a request must look like and how the mock responds. It’s Apache-2.0 licensed and supports HTTP, HTTPS, and more on a single port.

Honest limits: it’s a JVM server, so it’s heavier and slower to start than the Node tools, and expectation setup is more verbose than pointing at a spec. If you just need a spec served, that’s overkill; if you outgrow it, the MockServer alternatives comparison lays out the trade-offs.

WireMock (standalone)

WireMock is the other established JVM mock server, popular in the Java and JVM testing world. Its standalone jar runs the same engine you’d embed in a JUnit test, so a mock you build in local dev carries straight into your test suite.

java -jar wiremock-standalone.jar --port 8080

That serves on port 8080. WireMock reads stub mappings from a mappings/ directory or its JSON API, and it can also record real traffic and replay it as stubs, which is handy when you’re mocking a third-party API you don’t control. There’s an official wiremock/wiremock Docker image for CI.

Best for: JVM teams who want one mocking engine shared between local dev and their test suite, plus record-and-replay. It’s Apache-2.0 licensed.

Honest limits: like MockServer, it needs a Java runtime and starts slower than the Node options. Its stub-mapping JSON is powerful but more to learn than a one-file data mock. If you came from the JavaScript side, the Mock Service Worker (MSW) alternative comparison covers where WireMock fits against browser-first mocking.

Apidog CLI

The tools above each solve one slice of mocking. Apidog takes the integrated route: your API design, the mock, your tests, and your docs live in one project, and the Apidog CLI drives that project from the terminal. Apidog isn’t open source; it’s a commercial product with a free tier. But that free tier plus the CLI gives you an alternative to stitching a separate mock server, test runner, and spec tool together.

Apidog generates a smart mock automatically from every endpoint you define, with responses that follow your schema’s field types and naming, so a phone field returns a plausible phone number rather than a random string. When you need a specific response for a specific request, you add a mock expectation. The CLI manages those mock resources as part of the project:

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog mock --help

The mock command group works with your project’s mock expectations from scripts and CI, alongside command groups for endpoints, schemas, environments, and test runs. Output is structured JSON with an agentHints.nextSteps field, which makes it usable by AI agents as well as humans. The full command surface is covered in the Apidog CLI complete guide.

Best for: teams who’d rather keep the mock, the spec, and the tests in one place than run three separate tools. Download Apidog to try the built-in mock server and the CLI on your own project.

Honest limits: it’s a platform, not a single-purpose binary, so it asks for a project and a login where json-server asks for nothing. If all you need is a throwaway mock from one file, a lighter tool wins; if you’re already designing your API in Apidog, the mock is already there.

How to choose

Match the tool to what you already have. If you have an OpenAPI spec, Prism or Mockoon CLI serve it directly. If you have nothing yet, json-server invents an API from a JSON file. If you need exact request matching, reach for MockServer or WireMock. If you want the mock to live next to your design and tests, use Apidog.

The rough rule: npx tools for speed, JVM servers for matching depth, Apidog when you want one workflow instead of several. If you’re still deciding whether to mock at all, the walkthrough of API mocking use cases covers when it pays off.

Wrapping up

Lightweight mocking comes down to one question: what do you already have to feed the tool? A spec goes to Prism or Mockoon CLI. A blank slate goes to json-server. Strict matching goes to MockServer or WireMock. And if you’d rather not run and wire up several tools, Apidog keeps the mock next to the design and the tests, driven from the same CLI you’d script anyway.

All six run from the terminal, fit in a CI job, and get you a fake API in seconds instead of hours. Pick the smallest one that covers your case, and add weight only when you actually need it. To see the integrated version, Download Apidog and generate a mock server from your API design in one step.