ApiCatcher Schnellstart

ApiCatcher erfasst, zeigt und analysiert HTTP/HTTPS- und WebSocket-Traffic einer App lokal.

Diese Seite behandelt den Alltag: Zertifikate, Filter, Verlauf, Export und API-Dokumentation. Rewrite, Skripte, Combo-Replay und der Rest stehen in den Dokumenten darunter.

Weiterführend:

Inhalt

Zertifikate
Traffic-Filter
Capture-Sessions und Verlaufssuche
Cookie finden
HAR, Dateien und einzelne Requests exportieren
Automatische API-Dokumentation
API Scan

1. Zertifikate

1.1 CA-Zertifikat installieren und vertrauen (nötig für HTTPS)

Der Großteil des App-Traffics ist HTTPS. Standardmäßig erfasst ApiCatcher kein HTTPS: ohne vertrauenswürdiges CA gibt es nichts zu entschlüsseln. CA zuerst installieren und vollständig vertrauen, dann HTTPS anschauen.

Zwei Wege:

Die von ApiCatcher erzeugte CA (in den meisten Fällen die richtige Wahl). Schritte unten.
Eigenes Zertifikat importieren (Unternehmens-CA). Weiter bei 1.2.

Standard-CA:

In der App Zertifikat installieren tippen. iOS öffnet Safari und lädt ein Konfigurationsprofil.
Einstellungen → Allgemein → VPN und Geräteverwaltung: ApiCatcher-Profil installieren.
Dann Einstellungen → Allgemein → Info → Zertifikatsvertrauenseinstellungen, Zertifikat mit Präfix ApiCatcher CA suchen und volles Vertrauen einschalten.

Wenn etwas hakt

Timeouts oder merkwürdige Statuscodes: meist Schritt 3 ausgelassen.

App gelöscht und neu installiert: altes Profil ist tot. In den Einstellungen entfernen und die Schritte wiederholen.

1.2 Unternehmenszertifikate

Manche internen Apps vertrauen nur der Firmen-CA.

Zweck: .pem oder .p12 der Firma importieren und an interne Hosts binden (z. B. *.corp.internal), damit der lokale TLS-Handshake durchgeht.
Hinweis: Import oder Änderung nur bei gestoppter Erfassung, danach neu starten.

1.3 Selbstsignierte Zertifikate

Keine Firmen-CA und die ApiCatcher-CA soll nicht verwendet werden? Denselben Unternehmens-Flow nutzen und das eigene Zertifikat importieren. Siehe Eigene CA.

2. Traffic-Filter

System und Hintergrund-Apps erzeugen viel Rauschen. Filter entscheiden, was gespeichert wird.

Sperrliste: passende Hosts werden nicht aufgezeichnet. Leere Freigabeliste = alles außer Sperrliste.
Freigabeliste: sobald eine Regel existiert, werden nur passende Requests gespeichert.
Wildcards: * gilt. *.example-api.com trifft die Test-Subdomains dieses Hosts.

Wenn etwas hakt

Kein Traffic: Host steht auf der Sperrliste, oder die Freigabeliste ist an, der Host fehlt aber.

Einfacher Stern reicht (*.api.com). Keine regulären Ausdrücke an dieser Stelle.

3. Capture-Sessions und Verlaufssuche

Sperr-/Freigabeliste: was landet im Speicher. Danach auf Verlauf mit Session und Suche eingrenzen.

3.1 Capture-Session

Eine Session ist ein VPN-Capture-Lauf. Die UI zeigt die Startzeit (yyyy-MM-dd HH:mm:ss). Umbenennen geht nicht.

VPN-Start legt eine Session an. Stop schreibt Endzeit und Request-Zahl. Null Requests = Session wird gelöscht. Läuft die Erfassung, steht als Ende Capturing....

Der Session-Filter im Verlauf kann einen Lauf festnageln oder Alle zeigen. Der Picker zeigt Zeitraum, Dauer, Anzahl und bis zu fünf Hosts. Session löschen entfernt ihre Records.

3.2 Filter

Die Filterleiste im Verlauf ist konfigurierbar. Filter konfigurieren wählt die Chips, Filter zurücksetzen leert sie.

Filter	Abgleich
Session	Ein Lauf oder alle
Host	Exakter Host
App (UA)	App-Name aus dem User-Agent, exakt
Methode	GET / POST / PUT / DELETE / PATCH / OPTIONS / HEAD
Schema	HTTP / HTTPS / WS / WSS
Typ	Alle, HTML, JSON, XML, Bild, Video, Audio, Protobuf (Content-Type)
Status	1xx–5xx plus Keine Antwort
Zeit	Letzte 15 Minuten, letzte Stunde, heute, letzte 7 Tage, letzte 30 Tage, eigener Bereich

3.3 Stichwortsuche

Das Suchfeld trifft standardmäßig URL (Platzhalter: Search url...). Groß-/Kleinschreibung egal, Teilstring. Kein Regex, kein AND / OR.

Ziel ändern über Verlauf … → Suchziel wechseln:

Ziel	Bereich
URL	Request-URL
Request-Header	Namen oder Werte
Response-Header	Namen oder Werte
Request-Body	Body-Text
Response-Body	Body-Text

Body-Suche liest nur Text-Content-Types (HTML / XML / JSON / Plaintext / form-urlencoded / form-data). Bilder, Video und andere Binärbodies bleiben außen vor.

4. Cookie finden

Cookie finden holt den Cookie-Header der jüngsten Request zu einem Host. Kein Set-Cookie, keine Zusammenführung über Requests.

Verlauf öffnen.
Oben rechts … → Cookie finden.
Host eingeben (Pflicht; aus bereits erfassten Hosts oder frei tippen).
Optional Session. Leer = alle Sessions.
Cookie suchen.

Treffer: Aktuelles Cookie plus Name/Wert. Sonst: Kein Request mit Cookie.

5. HAR, Dateien und einzelne Requests exportieren

5.1 Als HAR exportieren

HAR 1.2 JSON, importierbar in Charles, Fiddler, Burp usw. Dateiname etwa apicatcher-export-yyyyMMddHHmmss.har.

Einstieg	Umfang	Folgt den aktuellen Filtern
Verlauf Als HAR exportieren	Alle Requests des Filterergebnisses (nicht nur die sichtbare Seite)	Ja (Session, Host, Zeit, Methode, Typ, Status, Suchwort — wie die Liste)
Mehrfachauswahl, dann teilen / exportieren	Nur die markierten	Nein
Favoritenordner → HAR	Requests in diesem Ordner	Nein

Die UI sagt: Total requests to export: N. You can modify filters to change the requests to export. Seite während des Exports nicht verlassen.

5.2 Bilder / Video / Audio

Einstieg: Dateiverwaltung im Verlauf (Ordner-Icon).

Drei Körbe: Bild, Video, Audio.
Eingrenzen über Session und Host.
Range / Content-Range-Stücke werden vor dem Export zusammengefügt.
Einzeldatei oder ZIP nach Host gruppiert.

Im Request-Detail geht auch Datei exportieren am Request- oder Response-Body; der Typ folgt dem Content-Type.

5.3 Einzelnen Request

Im Detail Request exportieren:

Raw: originales HTTP Request + Response (.txt)
cURL: im Terminal wiederholbarer Befehl (.sh)
Markdown: Markdown-Vorschau (.md)

6. Automatische API-Dokumentation

Passende HTTP/HTTPS-Requests erzeugen oder aktualisieren die API-Doku lokal, gruppiert nach Host. Dieselbe Schnittstelle erneut gesehen: nur neue Felder kommen dazu, vorhandene Parameternamen bleiben.

6.1 Was dokumentiert wird

Nur HTTP/HTTPS mit Response und Status außerhalb 301–308. Request-Content-Type JSON / XML / multipart/form-data / x-www-form-urlencoded, oder Response JSON / XML. Bilder, Video, HTML, Plaintext: übersprungen.

Von Rewrite oder Skript veränderte Requests kommen nicht in die Doku. Schlüssel: Methode + Host + Path (z. B. GET + api.example.com + /v1/user).

Merge:

Query, Header, Body: nur fehlende Namen ergänzen.
Body-Beispiel: nur bei Response-Status 200 aktualisieren.
Übliche Standardheader wie Cookie und User-Agent bleiben draußen. Authorization, Content-Type und eigene Header bleiben.

6.2 Nach Postman / Apifox / Bruno

Einstiege:

Export aus der API-Liste eines Hosts (alle Endpoints dieses Hosts).
Export aus der Detailseite einer API (nur dieser Endpoint).
Einstellungen → API-Favoriten → Export nur für Favoriten.

Ziel	Vorgehen
Nach Postman exportieren	Postman-API-Key → Workspace laden → neue Collection oder bestehende wählen
Nach Apifox exportieren	Apifox-API-Key und Projekt-ID; Ordner-ID optional (leer = Wurzel)
Nach Bruno exportieren	ZIP mit `bruno.json` und `.bru`; in Bruno Open Collection

Schritt-für-Schritt:

7. API Scan

API Scan geht den lokal erfassten Traffic durch: Qualität, offensichtliche Leaks, Latenz. Analyse bleibt auf dem Gerät.

7.1 Eingebaute Checks

Sensible Daten: Telefonnummern, Ausweisnummern, E-Mails, Cloud-Credentials (AWS-Key, OpenAI-API-Key) im Klartext.
Stacktraces: Java-, Python- oder SQL-Fehlerstacks in einem Response-Body.
Zu häufige Calls: mittleres Intervall unter dem gesetzten Schwellwert — oft eine Schleife oder ein Retry-Bug.
Latenz: p95 / p99 pro Endpoint.

7.2 Custom Scan

JS für eigene Regeln.

null, wenn der Request in Ordnung ist. Sonst eine kurze Notiz (≤200 Zeichen): Body zu groß, Security-Header fehlt, … Die Notiz landet im Report.

Wenn etwas hakt

Keine Treffer: Im Scan-Scope (Host / Session) wirklich JSON/API, nicht nur statische Assets? Pro Lauf gibt es eine Obergrenze.