The screen is designed, the client code is written, and the endpoint it needs ships "next sprint". Every frontend and mobile developer knows this week. Here are three ways to stop waiting, when each one is the right call, and the edge cases you should be mocking anyway, even after the real API exists.
Option 1: mock inside the app
Fixtures, a fake HTTP client, or a request-interception library such as MSW for web and Node.
Good for: unit and component tests, fast feedback, no network at all.
Weak at: anything outside the test runner. A tester on a real device gets the real (missing) endpoint, and the mock code is one more thing that drifts from the spec.
Option 2: run a standalone mock server
Point a mock server such as Stoplight Prism at your spec and switch the app's base URL to it.
Good for: a whole API that does not exist yet, contract-first teams, local development.
Weak at: mixing. It mocks everything, so the endpoints that already work in staging are mocked too, and the app needs a different base URL (which means a different build or config) to use it.
Option 3: mock at the proxy
Route the app through a debugging proxy that answers only the endpoints that are missing and passes everything else to the real backend. The app keeps its real URLs, so nothing changes in the code when the endpoint ships: you delete the mock.
Good for: one or two missing endpoints in an otherwise real API, manual testing on real devices, and QA testing against the same mocks as the developers.
Weak at: the usual proxy setup. The device has to use the proxy and trust its CA.
The edge cases worth mocking even when the API exists
A mock that only returns the happy path is half a mock. For every list or detail endpoint, try:
| Response | What it tells you |
|---|---|
Empty list [] | Is there an empty state, or a blank screen? |
401 | Does the app refresh the token or log the user out cleanly? |
404 on a detail route | Does a deleted item crash the screen? |
500 | Is there an error state with a way to retry? |
| A 3 second delay | Is there a loading state, and can the user leave? |
| Malformed JSON | Does the parser failure crash the app or get handled? |
The backend will almost never produce these on demand. A mock produces them in seconds.
The shared version
(17-second animated explainer, not a screen recording.)
Disclosure: I build Proxycept, a hosted debugging proxy, and option 3 is what it does for mocks. You upload an OpenAPI 3 spec or a Postman collection and get a mock route per operation; response bodies come from the spec's examples, or from placeholders built from the schema when there are none. Then you edit a route to return what you need: an empty list, a 401, a 500, or a delay. Anything you have not mocked goes to the real backend, unless you turn on catch mode, which blocks everything that is not mocked (handy for proving a demo or a test run has no hidden live dependency).
Because the proxy is hosted, the phone on a tester's desk, the emulator on your laptop and a CI runner all hit the same mocks through one endpoint. When something looks wrong, you can share the capture as a read-only link instead of a screenshot.
The limits: each device still has to trust the proxy's CA (manual on Android, like with any proxy), it does not get past certificate pinning, and it is for testing your own apps. If everything you test runs in one browser, option 1 is probably enough.
Free plan to start, sign in with Google, GitHub or email: proxycept.com. Related, if you want to capture real responses and replay them later: record and replay HTTP requests.
Which option does your team use, and what made you pick it? I'd like to hear it in the comments.
