Mock API server: run a fake API on your own computer

A mock API is a fake version of an API that you control. Your app calls it exactly as it would call the real one, and it answers with responses you decided on. You use one when the real API is not ready, is slow, costs money per call, is shared and fragile, or when you need it to return an error you cannot easily cause for real.

Zyvra is a mock API server that runs on your own computer. It is one small free program: no account to create, no cloud service, nothing to host. Your mocks, and the requests they answer, stay on your machine.

Start a mock API in a minute

Install it, create a project, and start it:

curl -fsSL https://www.zyvra.dev/install.sh | sh
zyvra init my-project
zyvra up

On Windows, use irm https://www.zyvra.dev/install.ps1 | iex to install. Your browser opens the dashboard. Create a mock service (it listens on its own local port), add an endpoint such as GET /products, give it a response, and call it:

curl http://127.0.0.1:8080/products

(Use the port you chose for the service.) Your app only has to point its base URL at the mock. See the quick start for the full walk-through.

What a mock can do

A mock that always returns the same JSON is easy. A mock that behaves like the real service is what makes testing worthwhile, so Zyvra goes further:

• Rules choose the answer from the request: its path, query, headers or body. The first rule that matches wins, so amount > 1000 can return “in review” while a known test card number returns “declined”.
• Scenarios are named responses for one endpoint (happy path, error, empty list). Switch between them with a click, or from the command line with zyvra scenario activate.
• Stored state lets a mock remember. Create an order with POST /orders, read it with GET /orders/{id}, list it with GET /orders, and it is still there after a restart.
• Responses that use the request. Put values from the path, query or body into the answer, so GET /products/7 returns product 7.
• Webhook callbacks. After an endpoint answers, Zyvra can send a request of its own (a webhook) to another service, immediately or after a delay.
• Failures on purpose. Make an endpoint slow, drop the connection, or return errors. See testing API failures.
• JavaScript for the cases that need real logic, running in a sandbox that is off until you trust the project.

Make a mock from what you already have

You do not have to type every endpoint:

• From an OpenAPI spec: see creating a mock API from an OpenAPI spec.
• From a browser recording (HAR): save the Network tab, pick the calls, and the mock can answer the way the real API did.
• From a collection of saved requests, including one imported from Postman.

Why run a mock locally

• No signup, no quota, no latency. It is a process on your machine.
• Files you own. A project is plain YAML in your folder. Review it in a pull request and keep it in Git next to the code it mocks.
• Private by default. The mock listens on 127.0.0.1, so nothing outside your computer can reach it, and your internal URLs and tokens are not sent anywhere.
• The same mock in CI. Run it from the command line in a pipeline, so tests do not depend on a real service being up. See API tests in CI.

If you are choosing between tools, mock API tools compared says when each one fits.