FetchSandbox

O sandbox mantém estado entre chamadas, então um cliente que você cria continua lá quando você o cobra, e os webhooks disparam como um serviço real faria. Isso importa. A maioria dos bugs de integração vive na sequência, não em uma única requisição. Ele se comporta como a API ao vivo e deixa a produção intacta. Sem chaves reais e sem cobranças reais durante o desenvolvimento.

O FetchSandbox se apresenta como motor de verificação, não como uma simples ferramenta de teste de API. Quando seu agente afirma que corrigiu algo, a ferramenta roda o mesmo cenário contra o código antigo e o novo. A correção só conta se a execução falha antes e passa depois, o que transforma um vago "parece bom" em um código de saída. A meta declarada da empresa é um veredito que você pode automatizar, não a opinião de um colega.

O servidor MCP conecta o sandbox aos assistentes de código com IA mais usados, e a CLI cobre os fluxos pelo terminal. Os dois são de código aberto sob licença MIT. O motor hospedado, os sandboxes e a simulação de webhooks são o que você paga. Essa separação é útil se você quer ler o código de integração antes de confiar seu repositório a ele.

Os webhooks são a parte que a maioria das configurações de teste pula, e é onde o FetchSandbox concentra o esforço. Você pode duplicar um webhook, entregar eventos fora de ordem ou disparar um evento antigo para ver como seu handler reage. Cada fluxo lista os eventos de webhook obrigatórios e as invariantes como parte da especificação. "Funcionou de verdade?" finalmente tem resposta.

Cada execução gera uma URL de recibo que qualquer um pode abrir e repetir. Essa é a peça de confiança: você cola em um pull request ou em um thread do Slack e um revisor audita o que aconteceu sem confiar em uma captura de tela. Cada passo leva método, caminho, código de resposta e duração, e cada webhook leva um resultado de verificação de assinatura. Chega de adivinhação.

O catálogo já vem com suporte pronto para provedores como Stripe, Twilio, Resend, Clerk, Privy, AgentMail, Surge, Kulipa e WorkOS. Escolher um dá a você um sandbox funcional em minutos em vez de um servidor mock em branco. Os planos superiores deixam adicionar até cinco APIs suas a partir de uma especificação, que é onde equipes com serviços internos vão acabar.

Quando você adiciona uma segunda integração a um repositório que já tem uma, a ferramenta lê as duas e as conecta, e adicionar uma terceira lê as três. Em um exemplo documentado, um ID de usuário definido pelo Clerk flui para os metadados de pagamento do Stripe e depois para uma consulta no Resend. Servidores mock isolados não fazem isso. É o mais perto que o produto chega de como os repositórios reais são realmente montados.

Quando um cenário solicitado não se materializa, a ferramenta diz isso e explica por quê, em vez de reportar um teste aprovado falso. Em uma sessão publicada do Stripe, ela observou que um cenário de pagamento recusado não rodou porque o cartão de teste do caminho feliz do fluxo curado o sobrepunha, e depois listou os comandos exatos para exercitar esse ramo. Conhecer os limites da ferramenta é mais útil que um check verde em que você não pode confiar.