Fun API ist eine Übungsumgebung für API-Tests ohne Registrierung. Browser sandbox simuliert Anfragen im Browser; Live API verbindet sich über das Netzwerk mit dem Übungsserver. In wenigen Minuten kannst du deinen ersten Test ausführen.
Klicke auf der Startseite auf eine API-Karte. Die Seite im Swagger-Stil zeigt alle Endpoints nach Tags gruppiert. Grün steht für GET, Blau für POST, Orange für PUT und Rot für DELETE.
Der Katalog umfasst vier Gruppen: bekannte fiktive Welten, alltägliche Geschäftsbereiche, eigene Welten und Testszenarien. Wähle einen vertrauten Ablauf wie eine Pizzabestellung oder Flugbuchung, um dich auf HTTP zu konzentrieren.
Klappe einen Endpoint auf, klicke auf Try it out, fülle die Parameter aus, wähle Browser sandbox und dann Run request. Du erhältst einen simulierten HTTP-Statuscode, einen JSON-Body, Antwort-Header und einen kopierbaren curl-Befehl. Ein guter Einstieg:
GET /friends/v1/quotes/randomBrowser sandbox führt die API-Engine lokal aus; für diese Anfrage ist kein Netzwerkzugriff nötig. Szenariobezogene Verzögerungen und Ratenbegrenzungen können trotzdem gelten. Live API sendet eine echte Netzwerkanfrage an eine Cloud Function mit Firestore. Verwende in externen Clients die vollständige Adresse: https://funapi.dev/api/friends/v1/quotes/random.
Endpoints mit einem Schloss benötigen ein Bearer-Token. Öffne Authorize oben auf der Dokumentationsseite und verwende eines dieser Übungs-Token:
qa-admin-tokenqa-viewer-token403401 Unauthorized; gültige Token aus dem Login-Ablauf werden gesondert geprüftDie schreibenden Endpoints der Cargo API verwenden statt Bearer einen API-Schlüssel: Sende X-API-Key: cargo-key-123. So kannst du unterschiedliche Authentifizierungsverfahren üben.
Für einen Token-Lebenszyklus statt eines festen Werts verwende POST /auth/v1/login. Live API stellt ein signiertes JWT aus; die Browser-Sandbox simuliert den Ablauf lokal. Die OAuth-2.0-Endpoints bieten Authorization-Code-, Client-Credentials- und Refresh-Token-Abläufe zum Üben.
Erzeuge Fehlerantworten gezielt mit diesen Anfragen:
page=abc, einen ungültigen JSON-Body oder eine Bewertung von 11 senden999 oder eine Seite hinter der letzten Seite anfragenGET /coffee/v1/teapot — die absichtliche Teekannen-AntwortGET /bank/v1/premium/statements — eine simulierte BezahlschrankeGET /pizza/v1/oven/status — schlägt absichtlich immer fehlGET /protocol/v1/maintenance und GET /protocol/v1/gateway-timeout — Wartung und ZeitüberschreitungPOST /movies/v1/movies/{id}/poster — zu große Datei oder falscher DateitypDein Client sollte die Statuscodes unterschiedlich behandeln. Beachte bei 429 einen vorhandenen Retry-After-Header und verwende begrenzte Wiederholungen mit Wartezeiten. Wiederhole eine 403-Anfrage erst, wenn das Berechtigungsproblem behoben ist. Korrigiere bei 400 die Anfrage. Prüfe vor einer Wiederholung nach 503, ob der Vorgang sicher wiederholbar oder durch Idempotenz geschützt ist. Unbegrenzte Wiederholungen können einen Ausfall verschärfen.
Jede Dokumentationsseite bietet eine OpenAPI-3.1-Beschreibung und eine Postman-Collection zum Herunterladen. Importiere das vom jeweiligen Werkzeug unterstützte Format in Postman, Insomnia oder Bruno; die OpenAPI-Beschreibung kannst du im Swagger Editor prüfen. Ausgeführte Anfragen sind in neun Formaten verfügbar: curl, fetch, axios, Python, HTTPie, Playwright, RestAssured, C# und k6.
Neben den Downloads je API gibt es eine zusammengeführte Beschreibung aller APIs. Verwende sie, wenn dein Vertragstest mit einer einzigen Datei arbeiten soll.
Unterstützte PUT- und DELETE-Vorgänge für Figuren, Helden und Filme akzeptieren den optionalen Header If-Match. Ein veralteter ETag führt zu 412 Precondition Failed. Damit lässt sich prüfen, dass ein Client die Änderungen eines anderen nicht unbemerkt überschreibt.
Verwende Idempotency-Key bei POST-Endpoints, die diesen Header unterstützen. Wiederhole denselben Request mit demselben Schlüssel, um die ursprüngliche Antwort statt eines doppelten Datensatzes zu erhalten. Wähle dafür einen entsprechend dokumentierten Endpoint. Beide Mechanismen helfen, verlorene Änderungen und doppelte Vorgänge nach Netzwerkfehlern zu testen.
Aktiviere in Test settings den Deterministic mode, um Zufallswerte in der Browser-Sandbox reproduzierbar zu machen. Nutze für CI einen definierten Datenstand und klare Erwartungen. Warte im Browser-Test auf window.__funApiReset(), um lokale Daten ohne Bedienung der Oberfläche zurückzusetzen; der Aufruf setzt keine Live-Daten zurück.
Verwende die OpenAPI-Beschreibung mit einem Vertragstest-Werkzeug wie Dredd oder Schemathesis und prüfe dessen Unterstützung für die verwendete OpenAPI-Version. GET /pizza/v1/oven/preheat verzögert die Antwort um etwa drei Sekunden und eignet sich zum Testen eines Client-Timeouts.
Erzeuge für jeden unabhängigen Live-Testlauf eine eindeutige X-Sandbox-ID und sende sie bei allen Anfragen dieses Laufs mit. So überschneiden sich angelegte oder gelöschte Datensätze nicht mit anderen Testläufen. Diese Kennung ist kein Passwort oder Zugriffsgeheimnis; verwende keine echten personenbezogenen Daten.
POST, PUT und DELETE ändern die Sandbox-Daten der gewählten Umgebung: Lege eine Figur an und lies sie mit GET wieder aus. Ein Neuladen oder Reset sandbox data setzt die Browser-Daten zurück. Für Live-Daten verwende POST /api/_reset mit einem Admin-Bearer-Token; nur deine eigene Sandbox wird zurückgesetzt.
Direkt zur API springen: Friends API · Pokémon API · Star Wars API · Bank-API · Auth Playground API · Webhooks-API
Vertiefen Sie sich in eine Technik: API-Paginierung testen · API-Ratenbegrenzung testen · Idempotenz-Schlüsseltest · ETag- und If-Match-Test · Webhook-Signaturprüfung · OAuth- und JWT-Tests · Negativer Test · Asynchrone Jobtests
Oder schlagen Sie einen Statuscode nach: all 53 of them
Zuletzt aktualisiert