FetchSandbox

Le bac à sable conserve l'état entre les appels, donc un client que vous créez est toujours là quand vous le débitez, et les webhooks se déclenchent comme le ferait un vrai service. Cela compte. La plupart des bugs d'intégration vivent dans la séquence, pas dans une seule requête. Il se comporte comme l'API en direct tout en laissant la production intacte. Pas de vraies clés, pas de vrais débits pendant le développement.

FetchSandbox se présente comme un moteur de vérification, pas comme un simple outil de test d'API. Quand votre agent affirme avoir corrigé quelque chose, l'outil exécute le même scénario contre l'ancien et le nouveau code. La correction ne compte que si l'exécution échoue avant et passe après, ce qui transforme un vague « ça a l'air bon » en code de sortie. L'objectif affiché de l'entreprise est un verdict que vous pouvez automatiser, pas l'avis d'un collègue.

Le serveur MCP relie le bac à sable aux assistants de code IA les plus utilisés, et la CLI couvre les flux au terminal. Les deux sont open source sous licence MIT. Le moteur hébergé, les bacs à sable et la simulation de webhooks sont ce que vous payez. Cette séparation est utile si vous voulez lire le code d'intégration avant de lui confier votre dépôt.

Les webhooks sont la partie que la plupart des configurations de test sautent, et c'est là que FetchSandbox concentre ses efforts. Vous pouvez dupliquer un webhook, livrer les événements dans le désordre ou déclencher un événement périmé pour voir comment votre gestionnaire réagit. Chaque flux liste les événements de webhook obligatoires et les invariants dans sa spécification. « Est-ce que ça a vraiment marché » a enfin une réponse.

Chaque exécution produit une URL de reçu que n'importe qui peut ouvrir et rejouer. C'est la pièce de confiance : vous la collez dans une pull request ou un fil Slack et un relecteur peut auditer ce qui s'est passé sans croire une capture d'écran sur parole. Chaque étape porte une méthode, un chemin, un code de réponse et une durée, et chaque webhook porte un résultat de vérification de signature. Fini les devinettes.

Le catalogue embarque un support prêt à l'emploi pour des fournisseurs comme Stripe, Twilio, Resend, Clerk, Privy, AgentMail, Surge, Kulipa et WorkOS. En choisir un vous donne un bac à sable fonctionnel en quelques minutes plutôt qu'un serveur mock vide. Les offres supérieures permettent d'ajouter jusqu'à cinq API personnelles à partir d'une spécification, ce qui conviendra aux équipes avec des services internes.

Quand vous ajoutez une seconde intégration à un dépôt qui en a déjà une, l'outil lit les deux et les relie, et en ajouter une troisième lit les trois. Dans un exemple documenté, un ID utilisateur défini par Clerk alimente les métadonnées de paiement Stripe, puis une recherche Resend. Les serveurs mock isolés n'y arrivent pas. C'est ce qui rapproche le plus le produit de la façon dont les vrais dépôts sont réellement câblés.

Quand un scénario demandé ne se matérialise pas, l'outil le dit et explique pourquoi, au lieu de rapporter une fausse réussite. Dans une session Stripe publiée, il a noté qu'un scénario de paiement refusé n'avait pas tourné parce que la carte de test du chemin nominal du flux sélectionné le supplantait, puis il a listé les commandes exactes pour exercer cette branche. Connaître les limites de l'outil est plus utile qu'une coche verte à laquelle on ne peut pas se fier.