Cassez votre API
Pointez n'importe quel client vers le proxy, puis simulez une 500, mettez en pause une requête en plein vol, ou exportez exactement ce qui s'est passé sous forme de HAR à remettre à un coéquipier.
Reproduire un bug d'API signifie
Un endpoint lent, un corps d'erreur malformé, une course entre deux appels — rien de tout cela n'est facile à déclencher à la demande depuis un vrai serveur.
Pour les ingénieurs backend et full-stack qui construisent ou testent un client d'API — une appli mobile, un frontend, une CLI, un job CI — et qui ont besoin de voir et contrôler les octets exacts sur le fil, pas seulement la réponse renvoyée par un SDK.
Le proxy-server de Busymate se place entre votre client et l'API réelle. Chaque requête est capturée en direct, et le même moteur de règles bloquer/mocker/supprimer qui tourne sur la capture iOS et Chrome tourne aussi ici — vous pouvez donc répondre à une vraie requête par une réponse toute faite, ou la supprimer entièrement, sans toucher au backend.
Une URL PAC,
Pas de SDK, pas d'agent à installer — tout client pouvant être pointé vers un proxy est déjà intégré.
Simulez, bloquez ou supprimez sur le fil
Répondez à une requête correspondante avec votre propre statut, en-têtes et corps — ou supprimez-la — grâce à des règles exécutées directement dans le proxy, avant même que la requête n'atteigne la vraie API.
Point d'arrêt, éditer, renvoyer
Mettez en pause une requête en plein vol, éditez le HTTP brut à la main, puis continuez ou renvoyez-la — reproduisez une race condition ou une charge utile malformée sans écrire une ligne de code de test.
Export HAR, ou accès via REST
Exportez l'échange exact sous forme de fichier HAR pour un coéquipier ou un rapport de bug, ou accédez aux mêmes données capturées via l'API REST simple basée sur PostgREST — aucun SDK requis dans les deux cas.
- Proxy
- Dashboard
- REST
- MCP
D'un client instable à
Aucun changement de code d'un côté comme de l'autre.
- 01
Pointer le client vers le proxy
Configurez le client — un téléphone, un navigateur, un service backend, un job CI — depuis l'unique URL d'auto-configuration PAC. Le trafic commence à circuler immédiatement.
- 02
Reproduire l'échec
Simulez l'endpoint pour renvoyer la réponse cassée dont vous avez besoin, ou posez un point d'arrêt et éditez à la main la vraie requête ou réponse avant qu'elle ne continue.
- 03
Exporter ou interroger le résultat
Exportez l'échange en HAR à joindre à un rapport de bug, ou récupérez les mêmes entrées capturées depuis votre suite de tests via l'API REST.
Comment ça marche
Un proxy se place entre votre client et la vraie API ; les règles s'exécutent à l'intérieur.
- 01
Pointez un client vers votre proxy
Chaque appareil possède sa propre identité de proxy et une URL de configuration automatique. Collez cette URL dans les réglages Wi-Fi d'un téléphone, un profil de navigateur ou la variable de proxy HTTP que lit un backend ou une tâche CI, et ses requêtes arrivent immédiatement dans le flux du tableau de bord.
- 02
Écrivez une règle, ou mettez la requête en pause
Ouvrez une entrée et choisissez ce qui doit se passer la prochaine fois : répondre à la requête avec votre propre statut, vos en-têtes et votre corps, la rejeter, ou poser un point d'arrêt pour que la prochaine requête correspondante s'arrête en vol. Modifiez la requête ou la réponse brute à la main, puis continuez ou renvoyez-la.
- 03
Transmettez l'échange à quelqu'un d'autre
Exportez la requête et la réponse en fichier HAR pour un rapport de bug, ou lisez les mêmes entrées capturées depuis une suite de tests via l'API REST. Les deux contiennent les octets exacts qui ont transité sur le fil, pas l'interprétation d'un SDK.
Avant de pointer un client,
Mon client a-t-il besoin d'un SDK ou d'un changement de code ?
Non. Tout ce qui peut être pointé vers un proxy HTTP est déjà intégré — téléphones, navigateurs, services backend, tâches CI. Le proxy gère la capture et les règles ; votre client continue de parler à ce qu'il croit être la vraie API.
Puis-je simuler un seul endpoint et laisser le reste réel ?
Oui. Les règles correspondent à des motifs d'hôte et de chemin ; un endpoint peut donc renvoyer un 500 préparé pendant que toutes les autres requêtes passent intactes au vrai backend.
Un point d'arrêt bloque-t-il le reste du trafic ?
Non. Seule la requête correspondante s'arrête ; tout le reste continue de circuler. Continuez, modifiez ou renvoyez-la quand vous êtes prêt, et le client voit le résultat comme si le serveur avait répondu.
Mes tests peuvent-ils lire le trafic capturé ?
Oui. Les entrées capturées sont disponibles via une API REST simple ; un test d'intégration peut donc vérifier ce que le client a réellement envoyé plutôt que ce qu'un mock attendait.
Arrêtez de simuler le backend —
Pointez votre premier client vers le proxy et simulez, cassez ou renvoyez votre première requête en quelques minutes.