Brich deine API
Richte jeden Client auf den Proxy, simuliere dann einen 500er, pausiere eine Anfrage mittendrin, oder exportiere genau, was passiert ist, als HAR für ein Teammitglied.
Einen API-Bug zu reproduzieren bedeutet
Ein langsamer Endpunkt, ein fehlerhafter Error-Body, eine Race Condition zwischen zwei Aufrufen — nichts davon lässt sich leicht auf Abruf von einem echten Server auslösen.
Für Backend- und Full-Stack-Entwickler, die einen API-Client bauen oder testen — eine mobile App, ein Frontend, eine CLI, einen CI-Job — und die exakten Bytes auf der Leitung sehen und steuern müssen, nicht nur die Antwort, die ein SDK zurückgibt.
Busymates proxy-server sitzt zwischen deinem Client und der echten API. Jede Anfrage wird live erfasst, und dieselbe Block/Mock/Drop-Regel-Engine, die auf iOS und Chrome-Capture läuft, läuft auch hier — du kannst also eine echte Anfrage mit einer vorgefertigten beantworten oder sie ganz verwerfen, ohne das Backend anzufassen.
Eine PAC-URL,
Kein SDK, kein zu installierender Agent — jeder Client, der auf einen Proxy zeigen kann, ist bereits integriert.
Mocken, blockieren oder verwerfen auf der Leitung
Beantworte eine passende Anfrage mit eigenem Status, Headern und Body — oder verwirf sie — über Regeln, die direkt im Proxy laufen, bevor die Anfrage die echte API überhaupt erreicht.
Breakpoint, bearbeiten, erneut senden
Pausiere eine Anfrage mittendrin, bearbeite das rohe HTTP von Hand, dann fahre fort oder sende erneut — reproduziere eine Race Condition oder eine fehlerhafte Payload, ohne eine Zeile Testcode zu schreiben.
HAR-Export oder Zugriff über REST
Exportiere den exakten Austausch als HAR-Datei für ein Teammitglied oder einen Bugreport, oder greife über die einfache, auf PostgREST basierende REST-API auf dieselben erfassten Daten zu — in beiden Fällen kein SDK nötig.
- Proxy
- Dashboard
- REST
- MCP
Von einem instabilen Client zu
Keine Codeänderungen auf beiden Seiten.
- 01
Client auf den Proxy richten
Konfiguriere den Client — ein Telefon, ein Browser, einen Backend-Dienst, einen CI-Job — über die eine PAC-Auto-Config-URL. Der Traffic beginnt sofort zu fließen.
- 02
Fehler reproduzieren
Mocke den Endpunkt so, dass er die kaputte Antwort liefert, die du brauchst, oder setze einen Breakpoint und bearbeite die echte Anfrage oder Antwort von Hand, bevor sie weiterläuft.
- 03
Ergebnis exportieren oder abfragen
Exportiere den Austausch als HAR zum Anhängen an einen Bugreport, oder ziehe dieselben erfassten Einträge aus deiner Testsuite über die REST-API.
So funktioniert es
Ein Proxy sitzt zwischen deinem Client und der echten API; die Regeln laufen darin.
- 01
Einen Client auf deinen Proxy zeigen lassen
Jedes Gerät bekommt seine eigene Proxy-Identität und eine Proxy-Auto-Config-URL. Trag diese URL in die WLAN-Einstellungen eines Telefons, ein Browserprofil oder die HTTP-Proxy-Variable ein, die ein Backend oder ein CI-Job liest, und seine Requests landen sofort im Dashboard-Feed.
- 02
Eine Regel schreiben oder den Request anhalten
Öffne einen Eintrag und leg fest, was beim nächsten Mal passieren soll: den Request mit eigenem Status, Headern und Body beantworten, ihn verwerfen oder einen Breakpoint setzen, damit der nächste passende Request mitten im Flug anhält. Bearbeite Request oder Response roh von Hand, dann fortsetzen oder erneut senden.
- 03
Den Austausch weitergeben
Exportiere Request und Response als HAR-Datei für einen Bug-Report, oder lies dieselben erfassten Einträge aus einer Testsuite über die REST-API. Beide enthalten die exakten Bytes, die über die Leitung gingen, nicht die Interpretation eines SDK.
Bevor du einen Client umleitest,
Braucht mein Client ein SDK oder eine Codeänderung?
Nein. Alles, was auf einen HTTP-Proxy zeigen kann, ist bereits integriert — Telefone, Browser, Backend-Dienste, CI-Jobs. Der Proxy übernimmt Erfassung und Regeln; dein Client redet weiter mit dem, was er für die echte API hält.
Kann ich nur einen Endpunkt mocken und den Rest echt lassen?
Ja. Regeln matchen auf Host- und Pfadmuster, sodass ein Endpunkt einen vorgefertigten 500 liefern kann, während alle anderen Requests unverändert zum echten Backend durchgehen.
Blockiert ein Breakpoint den übrigen Traffic?
Nein. Nur der passende Request hält an; alles andere fließt weiter. Setz ihn fort, bearbeite ihn oder sende ihn erneut, wenn du bereit bist, und der Client sieht das Ergebnis, als hätte der Server geantwortet.
Können meine Tests den erfassten Traffic lesen?
Ja. Erfasste Einträge sind über eine schlichte REST-API verfügbar, sodass ein Integrationstest prüfen kann, was der Client tatsächlich gesendet hat, statt was ein Mock erwartet hat.
Hör auf, das Backend vorzutäuschen —
Richte deinen ersten Client auf den Proxy und mocke, brich oder sende deine erste Anfrage in Minuten erneut.