FetchSandbox

Die Sandbox behält den Zustand zwischen Aufrufen, also ist ein Kunde, den du anlegst, noch da, wenn du ihn belastest, und die Webhooks feuern so, wie es ein echter Dienst täte. Das ist wichtig. Die meisten Integrationsfehler stecken in der Reihenfolge, nicht in einer einzelnen Anfrage. Sie verhält sich wie die Live-API und lässt die Produktion unberührt. Keine echten Schlüssel, keine echten Abbuchungen während der Entwicklung.

FetchSandbox beschreibt sich als Verifikations-Engine, nicht als bloßes API-Testtool. Wenn dein Agent behauptet, etwas behoben zu haben, führt das Tool dasselbe Szenario gegen den alten und den neuen Code aus. Die Korrektur zählt nur, wenn der Lauf vorher scheitert und danach besteht, was ein vages "sieht gut aus" in einen Exit-Code verwandelt. Das erklärte Ziel des Unternehmens ist ein Urteil, das man automatisieren kann, nicht die Meinung eines Kollegen.

Der MCP-Server verbindet die Sandbox mit gängigen KI-Coding-Assistenten, und die CLI deckt terminalgesteuerte Workflows ab. Beide sind Open Source unter der MIT-Lizenz. Die gehostete Engine, die Sandboxes und die Webhook-Simulation sind das, wofür du zahlst. Diese Trennung ist nützlich, wenn du den Integrationscode lesen willst, bevor du ihm dein Repository anvertraust.

Webhooks sind der Teil, den die meisten Test-Setups überspringen, und genau hier investiert FetchSandbox seine Arbeit. Du kannst einen Webhook duplizieren, Ereignisse in falscher Reihenfolge zustellen oder ein veraltetes Ereignis feuern, um zu sehen, wie dein Handler reagiert. Jeder Ablauf listet die erforderlichen Webhook-Ereignisse und Invarianten als Teil der Spezifikation. "Hat es wirklich funktioniert" hat endlich eine Antwort.

Jeder Lauf erzeugt eine Beleg-URL, die jeder öffnen und nachspielen kann. Das ist das Vertrauensstück: Du klebst sie in einen Pull Request oder einen Slack-Thread, und ein Reviewer kann nachvollziehen, was passiert ist, ohne einem Screenshot blind zu glauben. Jeder Schritt trägt Methode, Pfad, Antwortcode und Dauer, und jeder Webhook trägt ein Signaturprüf-Ergebnis. Schluss mit Rätselraten.

Der Katalog bringt fertige Unterstützung für Anbieter wie Stripe, Twilio, Resend, Clerk, Privy, AgentMail, Surge, Kulipa und WorkOS mit. Wählt man einen davon, hat man in Minuten eine laufende Sandbox statt eines leeren Mock-Servers. Höhere Tarife lassen bis zu fünf eigene APIs aus einer Spezifikation hinzufügen, und dort landen Teams mit internen Diensten.

Wenn du eine zweite Integration zu einem Repository mit schon einer hinzufügst, liest das Tool beide und verbindet sie, und eine dritte liest alle drei. In einem dokumentierten Beispiel fließt eine von Clerk gesetzte Nutzer-ID in die Zahlungsmetadaten von Stripe und dann in eine Abfrage bei Resend. Isolierte Mock-Server können das nicht. Näher kommt das Produkt der echten Verdrahtung realer Codebasen nicht.

Wenn ein angefragtes Szenario nicht zustande kommt, sagt das Tool das und erklärt, warum, statt ein falsches Bestehen zu melden. In einer veröffentlichten Stripe-Sitzung vermerkte es, dass ein Szenario mit abgelehnter Zahlung nicht lief, weil die Testkarte des Happy Path im kuratierten Ablauf es übersteuerte, und listete dann die genauen Befehle, um diesen Zweig zu prüfen. Die Grenzen des Tools zu kennen ist nützlicher als ein grüner Haken, dem man nicht trauen kann.