Mock an API response locally
Sometimes you need the API to say something it won't say on demand: an empty list, a specific error, a field that isn't live yet. Instead of waiting on the backend or spinning up a fake server, you can have a proxy on your Mac answer for it. The client never knows the difference.
Three ways to fake a response
A debugging proxy sits between your app and the server, so it can answer a request itself. In elcapture that's a rule you point at a URL:
MAP LOCAL
Serve a file as the response
Write the JSON you want in a file and map the request to it. Every call to that URL returns your file, with a status and content-type you choose. This is the cleanest way to develop a screen against data the backend doesn't return yet, or to reproduce the exact payload from a bug report.
REWRITE
Change part of the real response
When you want the real response but with one thing different — flip a feature flag to true, blank a field, swap a URL — a rewrite rule edits the body or headers as they pass through. The rest of the response stays live.
FORCE AN ERROR
Return a 500, 429 or timeout
Map the URL to a chosen status code, or add a delay, to see how your app handles a server error, a rate limit or a slow network. Testing the sad path is usually harder than the happy path, and this makes it a two-click setup instead of a backend change.
One-off vs always-on
For a single request, set a breakpoint, let the response pause, and edit it by hand before it reaches the app — good for a quick what-if. For something you'll hit repeatedly, make it a rule so every matching call is mocked without you watching. Both live in the same window as the real traffic, so you can see exactly what you changed.