Product Thumbnail

Mockphine

Mock blocked APIs, passthrough ready routes, see live source

API
Developer Tools

Hunted byTa-Cuong NguyenTa-Cuong Nguyen

Mockphine keeps frontend and QA moving when backends are unstable. It lets teams mock blocked endpoints, pass through ready ones, and prove exactly what served each response; control unmatched routes with strict 404 or fallback passthrough; and inspect served-by source, status, duration, headers, and bodies in Live View. Deterministic matching plus delay/failure simulation helps catch integration bugs before release.

Top comment

Hey Product Hunt! I'm Cuong, maker of Mockphine. I built this after too many releases where frontend and QA were blocked by unstable or incomplete backend APIs. Most workflows forced a bad tradeoff: fully mocked (fast but unrealistic) or fully staging (real but flaky). I started with a tiny local mock server, then evolved it with feedback into: 👉 Route-level modes: Mock / Passthrough / Disabled 👉 Unmatched-route fallback control: strict 404 or passthrough 👉 Live View that shows served-by source + full request/response details 👉 Delay/failure simulation for edge-case testing 🎯 Help small teams ship faster without losing API confidence. Would love feedback from the community: what's the hardest API integration scenario for your team to test locally today?

Comment highlights

Delay and failure simulation for edge-case testing is genuinely underrated. Most teams only discover timeout handling and degradation bugs in production. Question: can delay/failure rules be saved as reusable test scenarios, or do you configure them fresh each session?

Congratulations! The “fully mocked vs. fully staging” dilemma is one of those chronic engineering tax problems that never quite makes it onto the roadmap because it feels like infrastructure debt rather than a feature. Does Mockphine support response templating? E.g., can I define dynamic mock responses based on request parameters, or is it static fixture-based for now?

Hi Cuong, really smart design on the route-level mock/passthrough modes — I've hit exactly this problem before. I'm a full-stack engineer (Next.js, TypeScript, Node.js) and would love to help build Mockphine further. Is there a way to reach you?

How does Mockphine implement deterministic route matching when multiple mock rules overlap, and how is precedence resolved between mocked endpoints and passthrough routes?