1
0 Comments

Why I built a mock API tool that's designed to lie to you

I kept running into the same problem: every mock API tool I tried

covered the happy path fine, then fell apart the moment I actually

needed to test what my client did when the real API misbehaved —

timeouts, flaky 500s, rate limits, malformed responses. I'd either

hand-roll that in test code every time, or just skip it and hope. So I

built MockBase, a hosted mock API tool built around the opposite

assumption: failure is the interesting case, not an afterthought. You

can define REST, GraphQL, or SOAP endpoints with conditional responses

based on query params, headers, or body content, inject failure on

purpose through weighted chaos scenarios and deterministic rate-limit

simulation so you can reproduce a specific failure instead of hoping

one happens, keep state across requests for flows that aren't

single-request, import an existing OpenAPI spec instead of building

from scratch, and every change keeps version history with diffs so

changing a mock under a teammate doesn't silently break their tests.

It's a side project, currently in beta — every signed-in account gets

the full feature set for free while I validate it before I think about

charging anyone. I'd genuinely like feedback from other founders here:

if you mock APIs today for frontend dev, contract testing, or CI, is

failure/chaos testing something you've wanted and skipped, or a solved

problem for you already? And if you've dealt with self-promotion

fatigue on IH, any advice on how much of this kind of post is too

much?

posted toAvatar for product MockBase
MockBase