FetchSandbox

El sandbox guarda estado entre llamadas, así un cliente que creas sigue ahí cuando lo cobras, y los webhooks se disparan como lo haría un servicio real. Eso importa. La mayoría de los errores de integración viven en la secuencia, no en una sola petición. Se comporta como la API en vivo mientras deja producción intacta. Sin claves reales y sin cargos reales durante el desarrollo.

FetchSandbox se presenta como motor de verificación, no como una simple herramienta de pruebas de API. Cuando tu agente afirma que arregló algo, la herramienta ejecuta el mismo escenario contra el código viejo y el nuevo. El arreglo solo cuenta si la ejecución falla antes y pasa después, lo que convierte un vago "se ve bien" en un código de salida. El objetivo declarado de la empresa es un veredicto que puedes automatizar, no la opinión de un compañero.

El servidor MCP conecta el sandbox con los asistentes de código con IA más usados, y la CLI cubre los flujos desde la terminal. Ambos son de código abierto bajo licencia MIT. El motor alojado, los sandboxes y la simulación de webhooks son lo que pagas. Esa separación es útil si quieres leer el código de integración antes de confiarle tu repositorio.

Los webhooks son la parte que más se salta la mayoría de las configuraciones de prueba, y ahí es donde FetchSandbox pone su esfuerzo. Puedes duplicar un webhook, entregar eventos fuera de orden o disparar un evento antiguo para ver cómo reacciona tu manejador. Cada flujo lista los eventos de webhook obligatorios y las invariantes como parte de la especificación. "¿Funcionó de verdad?" por fin tiene respuesta.

Cada ejecución produce una URL de recibo que cualquiera puede abrir y repetir. Esa es la pieza de confianza: la pegas en un pull request o en un hilo de Slack y un revisor puede auditar lo que pasó sin fiarse de una captura de pantalla. Cada paso lleva método, ruta, código de respuesta y duración, y cada webhook lleva un resultado de verificación de firma. Se acabaron las conjeturas.

El catálogo incluye soporte ya listo para proveedores como Stripe, Twilio, Resend, Clerk, Privy, AgentMail, Surge, Kulipa y WorkOS. Elegir uno te da un sandbox funcional en minutos en lugar de un servidor mock en blanco. Los planes superiores dejan añadir hasta cinco APIs propias a partir de una especificación, que es donde acabarán los equipos con servicios internos.

Cuando añades una segunda integración a un repositorio que ya tiene una, la herramienta lee ambas y las conecta, y añadir una tercera lee las tres. En un ejemplo documentado, un ID de usuario puesto por Clerk fluye hacia los metadatos de pago de Stripe y luego a una consulta en Resend. Los servidores mock aislados no pueden hacer esto. Es lo más cerca que está el producto de cómo se cablean de verdad los repositorios reales.

Cuando un escenario solicitado no se materializa, la herramienta lo dice y explica por qué, en vez de reportar una prueba superada falsa. En una sesión publicada de Stripe, señaló que un escenario de pago rechazado no se ejecutó porque la tarjeta de prueba del camino feliz del flujo curado lo anulaba, y luego listó los comandos exactos para ejercitar esa rama. Conocer los límites de la herramienta es más útil que una marca verde en la que no puedes confiar.