API-Tester

Sende HTTP-Anfragen an jede REST-API und prüfe die Antwort – funktioniert mit öffentlichen Endpunkten und deinem localhost-Dev-Server

100 % kostenlos. Dieses Tool braucht unseren Server für die Arbeit. Was du sendest, wird dort verarbeitet und danach verworfen – nie gespeichert.

Requests are sent directly from your browser first, so localhost and 127.0.0.1 endpoints work too - it falls back to a server-side proxy only if the browser can't reach the target directly (usually a CORS-blocked public API).

arrow_upward

Baue links eine Anfrage und tippe auf Senden, um die Antwort hier zu sehen.

Jump to the next useful tool without leaving your flow.

See more

Über dieses Tool

Baue und sende HTTP-Anfragen (GET, POST, PUT, DELETE usw.) mit eigenen Headern, Query-Parametern und einem Request-Body und prüfe dann die volle Antwort – ähnlich leichtgewichtigem Testen im Postman-Stil direkt in deinem Browser. Anfragen gehen zuerst direkt aus deinem Browser raus, deshalb ist das Testen deines eigenen localhost-Dev-Servers möglich – ein servergehostetes Tool kann deine Maschine nie erreichen, dein eigener Browser schon. Wenn der Browser eine Anfrage nicht direkt abschließen kann (meist eine öffentliche API, die Cross-Origin-Anfragen blockiert), fällt er automatisch auf einen serverseitigen Proxy zurück, sodass die Anfrage trotzdem durchgeht.

Ablauf

Bereinige und validiere API-Daten

  1. 1Das JSON formatierenMach es lesbar und finde Syntaxfehler.Öffnen
  2. 2Bei Bedarf umwandelnWechsle zwischen JSON, XML, YAML oder CSV.Öffnen
  3. 3Versionen vergleichenSieh genau, was sich geändert hat.Öffnen
  4. 4Die Anfrage testenSchick sie und prüfe die Antwort.Du bist hier

So verwendest du dieses Tool

  1. HTTP-Methode und URL wählenWähle GET/POST/PUT/DELETE und gib den genauen Endpunkt ein, den du testen willst.
  2. Query-Params und Header hinzufügenSetze nötige Header wie Authorization und Content-Type plus beliebige Query-String-Werte.
  3. Body angeben, falls nötigBei POST/PUT/PATCH-Anfragen füge JSON oder ein anderes Payload-Format ein, das die API erwartet.
  4. Senden und Antwort prüfenPrüfe Statuscode, Header und Response-Body, um Verhalten zu validieren und schnell zu debuggen.

So testest du eine REST-API

Wähle die Methode (GET zum Lesen, POST zum Anlegen, PUT oder PATCH zum Ändern, DELETE zum Löschen), gib die URL ein, ergänze Header wie Authorization und Content-Type und bei Bedarf einen JSON-Body. Sende die Anfrage und prüfe Statuscode, Response-Header und Body.

Der Statuscode sagt, was passiert ist: 200 OK, 201 angelegt, 400 fehlerhafte Anfrage, 401 nicht angemeldet, 403 nicht erlaubt, 404 nicht gefunden, 429 Rate-Limit erreicht und 500 Serverfehler.

Warum es nutzen

  • Schnelles API-Debugging ohne Installation externer Desktop-Clients.
  • Unterstützt gängige Request-Methoden, Header, Params und Payload-Tests.
  • Zeigt volle Antwortdetails zur Fehlersuche am Backend-Verhalten.
  • Ideal für schnelle Endpunkt-Checks in Frontend- und Backend-Entwicklung.

Häufige Anwendungen

  • REST-Endpunkte während der Feature-Entwicklung testen.
  • Auth-Header und tokenbasierte Zugriffsflows validieren.
  • API-Fehlerantworten und Grenzfallverhalten prüfen.
  • Staging-APIs vor Release oder QA-Übergabe verifizieren.

Tipps für bessere Ergebnisse

  • Speichere Beispiel-Payloads für wiederholte Endpunkt-Tests, um das Debuggen zu beschleunigen.
  • Starte mit einem einfachen GET, um Konnektivität zu prüfen, bevor komplexe Body-Anfragen kommen.
  • Passe den Content-Type genau an die Erwartungen deines Backend-Parsers an.
  • Nutze realistische Testdaten, um produktionsnahe Fehler sicher zu reproduzieren.

Fehler, die du vermeiden solltest

  • Auth-Header vergessen und annehmen, der Endpunkt selbst sei kaputt.
  • JSON mit falschem Content-Type senden und Parse-Fehler falsch lesen.
  • Response-Header ignorieren, wenn du Caching oder CORS-Verhalten debuggst.
  • Nur Erfolgswege testen, ohne Fehlerantworten zu prüfen.

Häufig gestellte Fragen

Du kannst eigene Header (einschließlich Authorization-Header für Tokens/API-Keys) zu deiner Anfrage hinzufügen, sodass die meisten authentifizierten APIs testbar sind, solange du gültige Zugangsdaten hast, die du mitschicken kannst.

Anfragen werden zuerst direkt aus deinem Browser gesendet, und manche öffentlichen APIs, die keine Cross-Origin-Anfragen erlauben (keine permissiven CORS-Header), blockieren diesen direkten Versuch – dieses Tool wiederholt dieselbe Anfrage dann automatisch über einen serverseitigen Proxy, sodass die meisten öffentlichen APIs trotzdem funktionieren, auch wenn die direkte Browser-Anfrage blockiert wird.

Ja – weil die Anfrage direkt aus deinem eigenen Browser gesendet wird statt von einem Remote-Server, kann sie http://localhost oder 127.0.0.1 erreichen, genau wie jede andere Seite, die in deinem Browser offen ist. Dein lokaler Server muss die Anfrage trotzdem erlauben (CORS), was die meisten Dev-Frameworks in der Entwicklung standardmäßig tun.

Typischerweise Statuscode, Header und Body der Antwort – sodass du vollständig prüfen kannst, was ein Endpunkt wirklich zurückgegeben hat, nicht nur ob er erfolgreich war.

Wähl POST, PUT oder PATCH, setz den Header Content-Type: application/json und schreib gültiges JSON in den Body. Viele APIs antworten mit 400 oder 415, wenn der Header fehlt, selbst wenn das JSON korrekt ist.

200-299 heißt Erfolg (201 erstellt, 204 kein Inhalt); 401 bedeutet fehlende oder falsche Zugangsdaten, 403 bekannt, aber nicht berechtigt; 404 ist ein falscher Pfad; 429 eine Ratenbegrenzung; 500-599 sind Serverfehler.

Schick ihn in dem Header, den die API dokumentiert, meist Authorization: Bearer <token> oder einen Header wie X-API-Key, nicht in der URL, wo er in Logs und Verlauf landet. Nutz zum Ausprobieren einen Testschlüssel.

Related guides