MockBase

Hey! Maker here. I built MockBase because I kept hitting the same wall on every project: the frontend is ready to go, but the backend isn't — and "just wait" or "hardcode some JSON" both get old fast, especially once you need to test what happens when the real API times out, rate-limits you, or your app is expected to survive a request in a weird order. So instead of another static mock tool, I wanted something that behaves like a real API would: different responses depending on what you send it, state that actually persists between calls, and the ability to break it on purpose — a slow timeout, a truncated response, a dropped connection — since those are the paths that never get tested until they happen in production. It's still very much a living project, so if you hit something that doesn't work the way you'd expect, or there's a use case I haven't thought of, I'd genuinely like to hear about it here.

The live request inspector paired with stateful CRUD is a smart combination. Being able to see every call stream in as it happens, and then copy it straight to cURL or fetch, would save a lot of debugging time when frontend and backend are out of sync. Chaos injection for truncated bodies and dropped connections is also a useful addition that most mock tools skip.

The chaos injection is the part I'd use most. Timeouts and truncated bodies are exactly the paths that never get tested until production. Can a chaos rule fire only on every Nth request, or only after a certain stateful CRUD call? That would make it easy to reproduce "works the first time, fails on retry" bugs in CI.

Chaos injection plus stateful CRUD is the combination most mock servers skip: everyone handles the happy path, then you end up hand-rolling timeouts and 429s just to test retry logic. Two things I would want to pin down before pointing CI at this. Does a versioned save fork the stored state, so rolling back a bad edit cannot leave orphaned records behind? And can you seed a fixture set so each pipeline run starts from a deterministic state? Also curious whether the rate-limit simulation counts per endpoint or globally per API key.

The chaos injection plus live inspector combo is exactly what frontend testing usually lacks — being able to see the request stream while simulating timeouts and truncated bodies makes flaky-scenario testing way less painful. Rate limit simulation with deterministic 429s is another gap most mock servers ignore. Curious whether conditional matching supports GraphQL operation names out of the box.

The chaos injection options (truncated bodies, dropped connections, deterministic 429s after N requests) are exactly what's missing from most mock servers, which only ever return the happy path. Being able to test retry and backoff logic against a stable HTTPS URL, with every request streaming into the live inspector, looks really handy. Does the stateful CRUD reset between sessions, or can you snapshot it?

The chaos injection options like truncated bodies and dropped connections are a great touch, since those failure modes are usually painful to reproduce against a real backend. Do you plan to let teams share a mock with role-based access, so QA and frontend can work off the same versioned endpoint?

OpenAPI import paired with sandboxed Jinja2 is the part I would actually use when scaffolding a mock from a spec that already exists. If the spec uses oneOf with a discriminator, does import keep those as separate conditional routes, or does it flatten them to a single example body? And can a template read other Redis-backed CRUD records, or is the sandbox limited to the current request so it cannot leak another resource's state?

OpenAPI import paired with sandboxed Jinja2 is the part I would use when scaffolding a mock from an existing spec. If the spec uses oneOf with a discriminator, does import keep those as separate conditional routes, or flatten them to one example body? Can a template read other Redis-backed CRUD records, or is the sandbox limited to the current request?

For the live inspector, a useful safeguard would be automatic masking of Authorization headers, cookies, and common secret fields before requests are copied as cURL or shared with teammates. Synthetic fixtures can still accidentally include a real token. Does the inspector offer configurable redaction, and does that also apply to saved request history?

The chaos injection is what stands out for me. Testing a truncated body or a dropped connection is usually the part teams skip until it breaks in production. Can a single route mix chaos with conditional matching, e.g. fail only when a specific header is present?

Stateful CRUD mocks are the killer detail here — most mock servers only handle static JSON, so testing edit flows always breaks. The live inspector on top makes it easy to see what the frontend actually sent. Nice tool for frontend-first teams.

Mock as code is the piece that would sell this to my team. Pointing an MCP server at a mock means an agent can spin up and inspect its own endpoints in CI instead of maintaining fixture files by hand. One question on the versioned saves: can a CLI run pin to a specific version, so a pipeline reproduces the exact mock a failing test was written against?

The live inspector showing every request as it arrive is what would sell me — it turns a mock server into a debugging tool during frontend work. Have you considered a shareable inspector link so a teammate can watch requests without an account? That would make it handy for pair-debugging a flaky integration.

For parallel CI runs, can each test run get isolated CRUD state and a fresh rate-limit window, or are those shared by everyone using the same mock URL? Deterministic 429 testing is useful, but a documented reset or per-run namespace would help avoid tests affecting one another.

OpenAPI import/export is the feature that would get my team to adopt this — scaffolding a mock straight from our spec, and regenerating the spec as the mock evolves, closes the loop between API design and frontend work. One thing I'd love to see: versioning mocks alongside spec versions, so a frontend pinned to v1 of an API doesn't silently receive v2 responses when the spec changes. Also curious whether the personal API key supports scoped keys for CI, so a token leaked in build logs can't rewrite shared mocks.

Tried it without signing up: "Create your first mock" gave me a demo API with four routes and a live HTTPS URL right away. I called GET /users from my terminal and the request showed up in the inspector instantly (200, about 15 ms). Stateful CRUD and the failure modes are what I'd come back for, since retry and timeout paths rarely get tested. Question: how long does a mock created without an account stay alive?

Chaos injection plus deterministic 429s is the part I'd use most, since retry and timeout paths are exactly what a happy-path backend never exercises. Can a mock route accept multipart/form-data uploads and return a binary body (e.g. image/webp)? Mocking an image upload endpoint with a slow or truncated response would cover a lot of upload-UI testing.