ProxyCeptor for Frontend Developers: Build Against APIs That Do Not Exist Yet
Frontend developers use ProxyCeptor to keep building when the API is missing, wrong or slow: mock a new endpoint from the agreed contract, deep-merge a flag into a live response, force error and loading states, or redirect production UI to a local backend. It works with any framework because it intercepts fetch and XHR at runtime, with no code or config changes.
Problems frontend developers run into
Blocked by the backend
The endpoint is designed but not deployed, so the UI is built against hard-coded data that has to be removed later.
States you cannot reach
Loading skeletons, empty states and error screens are hard to see when the local API always answers in 20 ms.
Mock code leaking into the repo
Temporary if (MOCK) branches and fake interceptors get committed and sometimes shipped.
Environment switching
Pointing a deployed front end at a local API normally needs a rebuild or env change.
Workflows that fix them
Contract-first mocking
Mock the new endpoint with the JSON from the API spec and build the UI against it. When the real endpoint ships, switch the rule off. No code to delete. See mocking API responses.
Feature flags and plans
Deep-merge { "features": { "newCheckout": true } } into the real /config response to see a flagged feature without touching the flag service.
Loading and error states
Add a 4-second delay to see skeletons, or a 500 to check error boundaries. See latency simulation.
Debug production UI against local code
Rewrite https://api.yourapp.com to http://localhost:3000 in your browser only. See rewriting API URLs.
Example
{ "name": "Enable new checkout", "match": { "urlPattern": "*/api/config", "matchType": "wildcard" }, "response": { "body": { "enabled": true, "mode": "merge-json", "mergeValue": "{ \"features\": { \"newCheckout\": true } }" } }}Frequently asked questions
Does it work with React Query, SWR, Apollo or RTK Query?
Yes. Those libraries call fetch or XHR underneath, which is where ProxyCeptor intercepts.
How is this different from MSW?
MSW mocks live in your code and are ideal for tests. ProxyCeptor mocks live outside the code and are ideal for development, debugging and sharing with non-developers. See ProxyCeptor vs MSW.
Will it slow down my app?
Only matched requests are touched. Unmatched requests pass straight through the wrapped fetch/XHR.
Related guides
Try these workflows free
Create a free ProxyCeptor account to mock, delay, block and rewrite API traffic, then share the same rules with your team.