Skip to main content
Your code talks to ten, twenty, thirty third-party services. Payments, email, SMS, auth, commerce, inference. Every one of them is a surface for bugs — bugs that only surface when a real webhook fires, a real state machine transitions, or a real error payload arrives. Testing that code is the problem Mirra solves.

​
What Mirra is

Mirra is a runtime that provides faithful, stateful mirrors of the third-party APIs your application depends on. Point your code at a Mirra URL instead of the real vendor and it behaves identically — same webhook signatures, same state machine transitions, same error payloads, same idempotency enforcement — but without the real-world side effects. No money charged. No messages sent. No emails delivered. No accounts polluted. 
$ npx @mirrahq/cli up

→ detected: stripe, resend, twilio
→ provisioning mirrors…
✓ stripe    → https://stripe-a7k2.mirra.run
✓ resend    → https://resend-a7k2.mirra.run
✓ twilio    → https://twilio-a7k2.mirra.run

session ses_a7k2 ready in 1.8s
Your Stripe SDK client, pointed at stripe-a7k2.mirra.run, sees a real running implementation of Stripe’s API. Create a customer — they stay created. Cancel a subscription — webhooks fire on the correct schedule, signed with HMAC-SHA256 using the exact scheme Stripe uses.

​
What makes a mirror different from a mock

A mock returns a hardcoded response. A mirror runs a real process with real state.

Stateful

Every session gets its own SQLite database. Records you create persist. State machines transition on the right schedule. Nothing is hardcoded.

Faithful

Vendor-correct webhook signatures. Vendor-correct error payloads. Vendor-correct rate limits. Byte-for-byte parity, verified weekly against the live API.

Isolated

A thousand parallel CI runs don’t see each other. No shared-staging collisions. Teardown is instant.

Drop-in

A TLS proxy routes api.stripe.com to the mirror transparently. Your existing SDK clients work without URL changes.

​
Three ways to use Mirra

One runtime, three execution modes:
1

mirra up — for local development and staging

Provision mirror URLs and keep them running as long as you need. State accumulates naturally. Reset on demand.
2

mirra run <scenario.md> — for CI and agent validation

Execute a markdown scenario against provisioned mirrors. Get a pass/fail verdict and a satisfaction score. Gate your PR on the result.
3

@mirrahq/vitest — for your existing test suite

Drop a withMirra() wrapper into your Vitest config. Your existing tests run against mirrors instead of mocks. Zero code changes.

​
Who Mirra is for

Mirra is built for engineering teams shipping integration code that touches real vendors — payments, email, SMS, auth, commerce. Teams with 5–50 engineers, 10+ third-party integrations, and increasingly heavy AI-assisted coding via Claude Code, Cursor, or Copilot. If you’ve ever shipped a Stripe webhook handler that didn’t verify signatures correctly, a Twilio retry loop that didn’t back off, or a Resend bounce callback that got silently swallowed — this is built for you.

​
Where to go next

Quickstart

Install the CLI and run your first mirror in under two minutes.

Scenarios

Learn the markdown scenario format and the [D]/[P] evaluation system.

Coding agents

Wire Claude Code, Cursor, or any MCP-compatible agent into a Mirra session.

Vitest plugin

Drop Mirra into an existing Vitest suite without changing test code.
Mirra is in private beta. Real usage requires an access request at mirra.run/access. These docs are public and work standalone — no account required to read them.