An MSW alternative when you need a real URL

Honest split first: Mock Service Worker is a genuinely great library. If you're writing JavaScript unit or component tests and you want request interception inside the test process — per-test handler overrides, no network, mocks that target the real API URL without changing your app's base URL — MSW is the right tool and this page is not trying to talk you out of it.

But MSW has a hard boundary that sends people searching for alternatives: the mock only exists inside your JavaScript process. A service worker in your browser tab, or interceptors in your Node test runner — and nowhere else. Which means:

curl and Postman get nothing. You can't poke your own mock from a terminal.
Mobile apps get nothing. Your iOS/Android teammate can't call handlers that live in your React repo.
Backend services get nothing. A Go or Python service that consumes the same API can't use your mocks.
Anyone without your repo gets nothing. A designer, a QA contractor, an external agent — the mock isn't a URL you can send them.
It's code you write and maintain. Handlers, a generated worker file (npx msw init), setupWorker/setupServer wiring, conditional startup — heavy for "I just need data on a URL for a prototype." (And if you learned MSW from a pre-v2 tutorial, the rest.get(url, (req, res, ctx) => …) snippets don't work anymore — the v2 API changed the handler signature.)
State is DIY. Out of the box a handler returns what you tell it to; if you want a POST to actually persist so a later GET sees it, you write and maintain that logic yourself.

Mockbird is the other half: a hosted mock REST API on a real URL. Define resources (or pick a preset, or import an OpenAPI spec / db.json / CSV / Postman collection), get realistic seeded data and full stateful CRUD — reachable from a browser, curl, Postman, a phone, a backend, CI, or a teammate on another continent. No handler code, no service worker, no signup.

The 60-second version

# one curl, no signup — a whole seeded e-commerce backend
curl -X POST https://HOST/api/projects \
  -H 'content-type: application/json' -d '{"name":"shop","preset":"ecommerce"}'
# → {"id":"abc123","adminKey":"KEY", ...}   ← save both

curl https://HOST/m/abc123/products?limit=3
# → 3 seeded products, CORS on, writes persist

Prefer clicking? This link creates the same project in your browser — no account. Have an OpenAPI spec? Paste it at /app#import and get a live seeded mock of your actual API shape.

MSW concepts → Mockbird

MSW	Mockbird	Notes
`http.get('/products', …)` handler	a `products` resource	list/get/create/update/delete generated, plus filtering, sorting, pagination, relations
Hand-rolled response data	seeded realistic records	faker-style names/emails/prices/dates; or import your exact records from db.json/CSV
`HttpResponse.json(data, {status: 500})`	`?mock_status=500` on any URL	no handler edit, no rebuild — error/loading states guide
`delay(2000)`	`?mock_delay=2000`	plus `?mock_jitter=100-1500` random latency and `?mock_chaos=0.3` random failures
Stateful handlers you write yourself	stateful by default	POST persists; GET it back over REST or GraphQL
Per-test `server.use(…)` overrides	snapshot pinning	save named data states, serve any GET from one via `X-Mockbird-Snapshot` — parallel workers don't race
`onUnhandledRequest` logging	request inspector	last 50 requests: method, path, query, headers, body
`graphql.query(…)` handlers	generated GraphQL endpoint	typed schema from your resources, GraphiQL included
Handlers shared via your repo	shared via URL	send a teammate the base URL — nothing to install

Try it in 10 seconds (shared demo, no setup)

# seeded data with field projection
curl 'https://HOST/m/demo/products?limit=2&select=name,price'

# the states you'd write handlers for — as query params
curl -i 'https://HOST/m/demo/products?mock_status=503'
curl 'https://HOST/m/demo/products/1?mock_delay=2000'

# stateful: the write persists
curl -X POST https://HOST/m/demo/products \
  -H 'content-type: application/json' -d '{"name":"proof","price":9.99}'
# → returns {"id":31,…} — and GET /m/demo/products/31 now works

All against the shared demo project (resets daily).

Or use both — they compose

Plenty of teams keep MSW for unit tests and use a hosted mock everywhere MSW can't go. Two easy patterns:

Point the environment at Mockbird. Set API_BASE_URL to your project URL in dev/preview builds; your app code doesn't change, and now the mock also works for the mobile app, the designer's phone, and CI smoke tests against a deployed preview.
Rewrite in Playwright. Route your real API host to a Mockbird project (or a pinned snapshot) in e2e tests — example in the testing states guide. You get MSW-style interception at the browser level, backed by hosted stateful data instead of handler code.

Honest comparison

	MSW	Mockbird
What it is	free OSS library (JS/TS)	free hosted service
Reachable from	your JS process only	anything with HTTP: browser, curl, Postman, mobile, backend, CI, agents
Setup	write handlers + worker init + wiring	one curl or one click; no code
Mock data	you write it	seeded realistic data, or import your own
Stateful CRUD	DIY in handler code	default
Error/latency simulation	per-handler code	`?mock_status` / `?mock_delay` / `?mock_chaos` / `?mock_jitter` on any URL
Works offline	yes — no network at all	no — it's a real network call
Latency	zero (in-process)	real network latency
Mocks the real URL transparently	yes — intercepts requests to your actual API host	no — you point your app at a Mockbird base URL
Per-test isolation	excellent (`server.use`, reset between tests)	snapshot pinning + restore recipes
Dynamic programmable responses	full JS — anything you can code	custom routes with templating; less powerful than arbitrary code
Request cap	none	10,000/project/day

Written by the Mockbird maker — bias disclosed. Where MSW genuinely wins: in-process interception means zero network flakiness, zero latency, and tests that run offline; it mocks your real API URLs without touching app config; per-test handler overrides are cleaner than anything URL-based can be; and a handler is arbitrary JavaScript, so any conditional behavior you can imagine is expressible. For JS unit and component tests, keep MSW. When the thing you need is a URL — for a prototype, a mobile client, a backend consumer, a teammate, or CI hitting a deployed build — that's us.

Full API reference in the docs. More guides: Mirage JS alternative · mock API for React · free mock API tools compared · deterministic test data · testing loading & error states. Create your API →