Use case

Break your API on purpose.

Point any client at the proxy, then mock a 500, pause a request mid-flight, or export exactly what happened as a HAR you can hand to a teammate.

An Android phone, a browser and a backend server stream traffic into a central proxy hexagon on port 8888; one stream passes a block-and-script rule gate and comes out transformed, then one live stream flows on into a dashboard feed with green status codes. A globe marks upstream proxy routing. android browser server {} rules :8888 upstream live 200 201 200

The problem

Reproducing an API bug means faking the backend

A slow endpoint, a malformed error body, a race between two calls — none of these are easy to trigger from a real server on demand.

For backend and full-stack engineers building or testing an API client — a mobile app, a frontend, a CLI, a CI job — who need to see and control the exact bytes on the wire, not just the response an SDK hands back.

Busymate's proxy-server sits between your client and the real API. Every request is captured live, and the same block/mock/drop rule engine that runs on iOS and Chrome capture runs here too — so you can answer a real request with a canned one, or drop it entirely, without touching the backend.

How it solves it

One PAC URL, the whole toolkit behind it

No SDK, no agent to install — any client that can be pointed at a proxy is already integrated.

Mock, block or drop at the wire

Answer a matching request with your own status, headers and body — or drop it — using rules that run inline in the proxy itself, before the request ever reaches the real API.

Breakpoint, edit, resend

Pause a request mid-flight, edit the raw HTTP by hand, then continue or resend it — reproduce a race condition or a malformed payload without writing a line of test code.

HAR export, or hit it over REST

Export the exact exchange as a HAR file for a teammate or a bug report, or reach the same captured data over the plain PostgREST-backed REST API — no SDK required either way.

Surfaces involved
  • Proxy
  • Dashboard
  • REST
  • MCP

Walkthrough

From a flaky client to a reproducible bug report

No code changes on either end.

  1. 01

    Point the client at the proxy

    Configure the client — a phone, a browser, a backend service, a CI job — from the one PAC auto-config URL. Traffic starts streaming immediately.

  2. 02

    Reproduce the failure

    Mock the endpoint to return the broken response you need, or set a breakpoint and edit the real request or response by hand before it continues.

  3. 03

    Export or query the result

    Export the exchange as a HAR to attach to a bug report, or pull the same captured entries from your test suite over the REST API.

On the proxy

How it works at the wire

One proxy sits between your client and the real API; the rules run inside it.

  1. 01

    Point a client at your proxy

    Every device gets its own proxy identity and a proxy auto-config URL. Paste that URL into a phone's Wi-Fi settings, a browser profile, or the HTTP-proxy variable a backend or CI job reads, and its requests start landing in the dashboard feed immediately.

  2. 02

    Write a rule, or pause the request

    Open an entry and choose what should happen next time: answer the request with your own status, headers and body, drop it, or set a breakpoint so the next matching request pauses mid-flight. Edit the raw request or response by hand, then continue or resend it.

  3. 03

    Hand the exchange to someone else

    Export the request and response as a HAR file for a bug report, or read the same captured entries from a test suite over the REST API. Both carry the exact bytes that crossed the wire, not an SDK's interpretation of them.

FAQ

Before you point a client, the usual questions

Does my client need an SDK or a code change?

No. Anything that can be pointed at an HTTP proxy is already integrated — phones, browsers, backend services, CI jobs. The proxy handles the capture and the rules; your client keeps talking to what it thinks is the real API.

Can I mock only one endpoint and leave the rest real?

Yes. Rules match on host and path patterns, so one endpoint can return a canned 500 while every other request passes through to the real backend untouched.

Does a breakpoint block other traffic?

No. Only the matching request pauses; everything else keeps flowing. Continue, edit or resend it when you are ready, and the client sees the result as if the server had answered.

Can my tests read the captured traffic?

Yes. Captured entries are available over a plain REST API, so an integration test can assert on what the client actually sent rather than on a mock's expectations.

Stop faking the backend — control the real wire

Point your first client at the proxy and mock, break or resend your first request in minutes.

Ask your mate