Caso de uso

Rompe tu API a propósito.

Apunta cualquier cliente al proxy y luego simula un 500, pausa una solicitud a mitad de vuelo, o exporta exactamente lo ocurrido como un HAR que puedes entregar a un compañero.

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

El problema

Reproducir un error de API significa simular el backend

Un endpoint lento, un cuerpo de error mal formado, una condición de carrera entre dos llamadas: nada de esto es fácil de provocar a demanda desde un servidor real.

Para ingenieros backend y full-stack que construyen o prueban un cliente de API (una app móvil, un frontend, una CLI, un job de CI) y necesitan ver y controlar los bytes exactos en la red, no solo la respuesta que devuelve un SDK.

El proxy-server de Busymate se sitúa entre tu cliente y la API real. Cada solicitud se captura en vivo, y el mismo motor de reglas de bloquear/simular/descartar que corre en la captura de iOS y Chrome también corre aquí, así puedes responder una solicitud real con una prefabricada, o descartarla del todo, sin tocar el backend.

Cómo lo resuelve

Una URL de PAC, todo el kit de herramientas detrás

Sin SDK, sin agente que instalar: cualquier cliente que pueda apuntar a un proxy ya está integrado.

Simula, bloquea o descarta en la red

Responde una solicitud coincidente con tu propio estado, cabeceras y cuerpo, o descártala, usando reglas que corren en línea dentro del propio proxy, antes de que la solicitud llegue a la API real.

Breakpoint, edita, reenvía

Pausa una solicitud a mitad de vuelo, edita el HTTP crudo a mano, y luego continúa o reenvíala: reproduce una condición de carrera o un payload mal formado sin escribir una línea de código de prueba.

Exporta a HAR, o accede vía REST

Exporta el intercambio exacto como archivo HAR para un compañero o un reporte de error, o accede a los mismos datos capturados vía la API REST basada en PostgREST: en ningún caso se necesita SDK.

Superficies involucradas
  • Proxy
  • Dashboard
  • REST
  • MCP

Guía paso a paso

De un cliente inestable a un reporte de error reproducible

Sin cambios de código en ningún extremo.

  1. 01

    Apunta el cliente al proxy

    Configura el cliente (un teléfono, un navegador, un servicio de backend, un job de CI) desde la única URL de auto-configuración PAC. El tráfico empieza a fluir de inmediato.

  2. 02

    Reproduce el fallo

    Simula el endpoint para devolver la respuesta rota que necesitas, o pon un breakpoint y edita a mano la solicitud o respuesta real antes de que continúe.

  3. 03

    Exporta o consulta el resultado

    Exporta el intercambio como HAR para adjuntarlo a un reporte de error, o extrae las mismas entradas capturadas desde tu suite de pruebas vía la API REST.

En el proxy

Cómo funciona en el cable

Un proxy se sitúa entre tu cliente y la API real; las reglas se ejecutan dentro de él.

  1. 01

    Apunta un cliente a tu proxy

    Cada dispositivo tiene su propia identidad de proxy y una URL de configuración automática. Pega esa URL en los ajustes Wi-Fi de un teléfono, en un perfil de navegador o en la variable de proxy HTTP que lee un backend o un trabajo de CI, y sus peticiones empiezan a llegar al dashboard de inmediato.

  2. 02

    Escribe una regla o pausa la petición

    Abre una entrada y elige qué debe pasar la próxima vez: responder la petición con tu propio estado, cabeceras y cuerpo, descartarla, o poner un punto de interrupción para que la siguiente petición coincidente se pause en pleno vuelo. Edita a mano la petición o la respuesta en bruto y luego continúa o reenvíala.

  3. 03

    Pasa el intercambio a otra persona

    Exporta la petición y la respuesta como archivo HAR para un informe de error, o lee las mismas entradas capturadas desde una suite de pruebas por la API REST. Ambos llevan los bytes exactos que cruzaron el cable, no la interpretación de un SDK.

FAQ

Antes de apuntar un cliente, las preguntas habituales

¿Mi cliente necesita un SDK o un cambio de código?

No. Todo lo que pueda apuntarse a un proxy HTTP ya está integrado: teléfonos, navegadores, servicios backend, trabajos de CI. El proxy se encarga de la captura y de las reglas; tu cliente sigue hablando con lo que cree que es la API real.

¿Puedo simular solo un endpoint y dejar el resto real?

Sí. Las reglas coinciden por patrones de host y ruta, así que un endpoint puede devolver un 500 enlatado mientras todas las demás peticiones pasan intactas al backend real.

¿Un punto de interrupción bloquea el resto del tráfico?

No. Solo se pausa la petición coincidente; todo lo demás sigue fluyendo. Continúa, edita o reenvíala cuando estés listo y el cliente verá el resultado como si el servidor hubiera respondido.

¿Pueden mis pruebas leer el tráfico capturado?

Sí. Las entradas capturadas están disponibles por una API REST sencilla, así que una prueba de integración puede verificar lo que el cliente envió realmente en lugar de lo que un mock esperaba.

Deja de simular el backend: controla el cable real

Apunta tu primer cliente al proxy y simula, rompe o reenvía tu primera solicitud en minutos.

Ask your mate