Ruse Is Live: Mock API Responses in Chrome Without a Mock Server

Ruse is now live in the Chrome Web Store.

It is a Chrome extension for frontend developers and QA engineers who need to test API states that are hard to reproduce on demand.
The first version is intentionally small:

• capture a real browser request
• turn it into a local mock rule
• change the response
• reload your app
• test the UI state you actually need

No mock server.

No proxy setup.

No app-code changes.

The problem

Frontend development often gets blocked by API states that are technically possible, but practically annoying to reproduce.

• Maybe the backend endpoint is not ready yet.
• Maybe staging has the wrong data.
• Maybe you need the API to return a 500, but the backend is healthy.
• Maybe you need an empty list, but the shared environment has 400 records.
• Maybe QA found a bug in a permission state that nobody can reproduce anymore.

These situations are not rare edge cases. They are normal frontend work. The annoying part is that the usual workarounds can be heavier than the task itself.

Common workarounds

Mock servers
Mock servers are powerful. They are useful when a team needs a shared fake backend, stable contracts, or a full development environment. But sometimes you do not need a whole mock environment. Sometimes you just need one request to return one specific response for ten minutes.

Local fixtures
Fixtures are fast for isolated components, but they do not always match the real network flow of the app.

Authentication, request timing, retries, headers, routing, and runtime conditions can all matter.

Backend flags or special test data
This can work in mature teams, but it creates coordination overhead. You have to ask someone to create the state, wait for it, and hope it still exists when QA or design tries to reproduce the same screen.

Temporary code hacks
We have all done this.

Add a temporary throw. Hardcode a response. Comment out a fetch call. Edit something in DevTools. Change a local branch just to force the UI into one state.

It works, but it is fragile and easy to forget.

What Ruse does

Ruse takes a smaller approach. Instead of starting with a mock server or a config file, it starts with the request your app is already making in the browser.

The workflow is:

1. Open your app in Chrome.
2. Open Ruse.
3. See browser requests in the request log.
4. Pick the request you want to control.
5. Create a local mock rule.
6. Change the response body, status, headers, or delay.
7. Reload and test the UI state.

That is the core loop.
Real request -> local mock -> controlled UI state.

What you can use it for

Ruse is useful when you need to test states like:

• empty lists
• 500 errors
• 404 states
• slow responses
• malformed JSON
• permission errors
• expired sessions
• missing backend endpoints
• stable demo data

The point is not to replace every other API mocking tool. The point is to make one browser-level override fast enough that you actually use it during normal frontend work.

What v0.1.0 is not
The first version is not trying to be a full API platform.

• It is not an API client.
• It is not a complete mock server replacement.
• It is not a team collaboration suite yet.

That is intentional. The first version focuses on one question:

Can a frontend developer control a real browser request locally, quickly enough to test the UI state they need right now?

If that loop is useful, the product can grow from there.

Why local-first matters

For v0.1.0, Ruse is local-first. That means the first useful version should not require a complex account setup just to mock one API response in your browser.

The goal is to keep the initial workflow lightweight:

• install extension
• open app
• capture request
• create rule
• test state

Future versions can add better organization, sync, teams, and more advanced workflows. But the first version should earn trust by being simple.

Who should try it

Ruse is probably useful if you are:

• a frontend developer building against incomplete APIs
• a QA engineer testing edge cases
• a full-stack developer building frontend and backend in parallel
• a developer preparing a demo that needs stable data
• someone who keeps hardcoding API responses just to test UI states

It is especially useful if you have ever said:

I just need this one request to return something different for a few minutes.

What feedback would help most

The best feedback right now is specific and practical.

For example:

• Which request did you try to mock?
• Did the request log make sense?
• Was the rule editor clear?
• Did a permission feel scary or unclear?
• Did a mock fail where you expected it to work?
• Which API state did you want but could not create easily?
• What felt slower than it should?

That kind of feedback is more useful than generic praise.

What comes next

The next version is already in motion.

The focus is on:

• lighter permissions
• better rule organization
• cleaner local workflows
• faster request-log-to-rule flow

The product is live now, but it is still early enough that real user feedback can shape the next release.

Try it

If you build frontend against unstable APIs, try Ruse and send feedback.

Website: https://ruse.dev

Chrome Web Store: use the install link on the Ruse website after the production landing update is live.

If you test it on a real frontend workflow, I would love to hear what breaks, what feels unclear, and what should be easier.