Simula una respuesta de API en un dispositivo real

Abre el feed del dashboard y busca una petición real al endpoint. Si su fila muestra un cuerpo descifrado, ya estás listo. Si el host sigue apareciendo cifrado, añádelo a la lista de SSL proxy del dispositivo —desde las acciones de host de la fila o en los ajustes del dispositivo— y vuelve a provocar la llamada. En un host que pasa cifrado, el motor solo puede coincidir por nombre de host; la ruta es invisible, así que un mock preciso por ruta nunca se dispara.

Abre la página Blocks desde el menú de ajustes para una regla global, o ve al dispositivo y luego a Blocks para una regla que solo aplique a este teléfono. Añade una regla y rellena el método —o déjalo vacío para coincidir con cualquiera— y el patrón. Los patrones son los mismos comodines de host y ruta que usan los breakpoints: el host, una barra, la ruta, con un asterisco donde un segmento varía.

Pon la acción en Mock. Donde Block sirve para hacer fallar una llamada y Drop hace que parezca que la red desapareció, Mock sirve para satisfacerla: define el estado —por defecto 200—, las cabeceras que la app vaya a mirar y el cuerpo. Dale el Content-Type que tu app analiza; un cliente JSON que recibe una respuesta de texto fallará antes de leer un byte. Guardada como JSON, la regla queda así.

Guarda la regla y usa la app. La siguiente petición que coincida se responde sin salir nunca de la ruta de captura, y sigue apareciendo en tu feed, marcada como simulada, para que veas exactamente qué se falseó y confirmes que la regla hizo lo que esperabas. La app solo ve una respuesta de servidor normal: las respuestas sintéticas no llevan ninguna cabecera interna o identificativa, así que nada en la respuesta revela la interceptación.

Desactiva la regla con su interruptor cuando termines. Una regla desactivada no cuesta nada y conserva su forma para la próxima vez.

Algunos mocks deben ocurrir una sola vez. El caso clásico es un 401 sintético que hace creer a la app que su token caducó para que ejecute su flujo de renovación: si respondes así a todas las peticiones, la app renueva, reintenta, recibe otro 401 y gira para siempre. El campo Max runs limita cuántas veces puede dispararse una regla; al llegar al límite se desactiva sola y el editor muestra una insignia de autodesactivada, distinta de una regla que apagaste tú.

El contador se lleva por dispositivo y sobrevive a reconexiones y reinicios de la app, así que un límite de uno se dispara una sola vez en ese teléfono, no una vez por sesión. Una regla global con límite se suprime solo en el dispositivo que lo agotó y sigue disparándose en el resto de teléfonos de la flota. También puedes pedirle a BusyBro en lenguaje natural un mock 401 de una sola vez para un host, y escribe la misma regla.

Un cuerpo Mock es una cadena congelada. Cuando la respuesta tiene que depender de la petición —un id devuelto, una marca de tiempo, un campo parcheado en la respuesta real— cambia la acción de la regla a Script, o crea un script independiente en Settings y luego Scripts. Tienes un editor de código con autocompletado para los objetos de petición, respuesta y ayuda, y un panel Test que ejecuta tu script contra una entrada capturada real y muestra un diff de antes y después sin tocar el tráfico en vivo. La prueba en seco usa el mismo sandbox que el proxy en vivo, así que pasar la prueba significa que funciona en producción.

Un script que lanza una excepción o agota el tiempo falla en abierto: los bytes originales se reenvían y la entrada queda marcada en el inspector, de modo que un script roto nunca puede bloquear una conexión ni delatarse ante la app. Los scripts son de nivel administrador porque ejecutan código arbitrario en la ruta de captura.