Mock APIs. Simulate dependencies. Build without blockers.

Zyvra is an API workbench that runs on your machine: mock services, an API client and a test runner in one small program. No account, no cloud.

curl -fsSL https://zyvra-eight.vercel.app/install.sh | sh

Installs for your user only, no sudo. How the download is verified

FreemacOS, Linux, WindowsSigned releasesv0.3.0
The Zyvra dashboard overview of a sample Shop API project: two running mock services, request totals, error rate and latency
What it does

From "the API isn't ready" to "the tests are green"

Use the mock side, the client side, or both in one project.

Mock

Make a mock behave like the real thing

Stand in for a service that is not ready, is slow, or that you do not want to call. Decide what it answers from the request itself.

  • Rules pick a response by path, query, headers or body: the first match wins
  • Scenarios switch an endpoint between happy path, errors and edge cases, one service at a time or across all of them
  • Webhook callbacks you set a trigger for (a status, a rule, a value in the request), with auth, client certificates, and the answer saved into state; plus state and JavaScript responses
  • Make a mock from an OpenAPI spec, a browser recording or a collection, and bring it up to date when the spec changes
The endpoint editor showing two rules: amounts above 1000 get an in-review response, a test card number gets a decline
Break

Make it fail on purpose, the same way every time

Test what your client does when the other side is slow, down, rate limited or wrong, without waiting for it to happen.

  • Latency, errors, dropped connections, cut-off or corrupt bodies, a throttled connection, a request that never answers, and rate limits with Retry-After
  • Apply a fault to a share of requests, to every 3rd or the first 3, or only to requests that ask for it with a header
  • Ready-made situations: Slow 3G, a flaky mobile connection, fails three times then works, goes down after five requests
  • Write your own in a few lines of JavaScript: an outage that comes and goes, a quota per API key, a slowdown that grows
The Faults tab of an endpoint: a slow-response fault and an error fault, both applying only to requests that send an x-chaos header
Test

Send a request, see exactly what answered

A full API client that knows about your mocks: every response says which service, rule and scenario produced it.

  • Environments, variables, cookies, cURL import and code snippets
  • Basic, Bearer, API key, JWT and OAuth 2.0, plus client certificates
  • Pre-request and test scripts with suggestions, hover help and examples to start from
  • Import from Postman, OpenAPI, cURL or a browser recording (HAR), and export back to Postman
The API Client showing a 202 response with a note that mock payments matched the rule "large amount needs review" and a fault was injected
Organize

Keep a big API easy to find your way around

Collections stay usable with hundreds of requests: folders on one side, requests on the other, and how the last run went at the top.

  • Folders on the left with search and counts, requests on the right with search and paging
  • A folder or collection shares auth, headers and scripts with everything inside it
  • Move requests and folders between folders, and up or down within one
  • Run history that folds away until you want it
The Collections page for a collection with eight folders and 32 requests: the run history is one line, folders are listed on the left and requests on the right
Automate

Turn requests into tests, run them anywhere

Add checks to a request, then run the whole collection here, or in CI with one command and a JUnit report.

  • Assertions on status, headers, JSON paths and JSON Schema
  • JavaScript test scripts, with a Postman-compatible pm.* layer
  • Data-driven runs: one iteration per row of a CSV or JSON file
  • Run history per collection, and exit codes your pipeline understands
The Test Runner after running the Checkout flow collection: eight requests passed, eight checks
Observe

See every request your mocks answered

Nothing is a black box: each request is recorded with the rule and scenario that handled it, so a surprising answer is easy to explain.

  • A live stream of requests, with headers and bodies, that you can narrow to errors or to requests no route matched
  • "Why this response": which rule matched, which did not, and the values each one saw
  • Create a rule straight from a captured request
  • Secrets are masked before anything is stored
The Traffic list: requests to the payments and inventory services with their status codes, a count of failed requests, and filters for service, method and outcome
Built to be trusted

An API tool sees your tokens and your internal URLs. Zyvra keeps all of it on your machine.

You should not have to take our word for it, so most of this can be checked.

0accounts to create
0usage tracking
127.0.0.1the only address it listens on
Ed25519signature on every release

It runs on your machine

Everything listens on 127.0.0.1. Nothing is reachable from other computers, and there is no cloud service behind it.

Your projects are plain files

YAML in your own folder. Read them, review them, keep them in Git. Nothing is locked in a database you cannot open.

Secrets are encrypted, and out of the files

Mark a variable secret and its value is stored encrypted outside the project, then masked in responses, history and traffic.

Scripts only run if you allow them

JavaScript is code, so it stays off until you trust the project. It runs in a sandbox with no file, network or process access.

Releases are signed

Every release is signed with Zyvra's own key. Zyvra refuses an update the key did not sign, and never installs one without asking.

No account, no tracking

Zyvra reports nothing about you or your projects. The optional daily update check sends only a version, a system and an architecture.

Try it in two minutes

Install it, create a project, and send your first request to a mock. There is nothing to sign up for.