Verstecktes JSON API der Website: So finden Sie interne Endpunkte und reduzieren den Parser-Traffic

Der Parser zieht 400 KB HTML für acht Felder, die die Website sich selbst in der JSON-Antwort mit 8 KB zurückgibt. Der Unterschied von fünfzigmal ist nicht über „schönen Code“; es geht um die Rechnung für residente Proxys, bei denen Sie für jedes Gigabyte bezahlen. Lassen Sie uns untersuchen, wie man die interne API der Website findet, was im Jahr 2026 die Wiederholung behindert und wann man von dieser Idee Abstand nehmen sollte.

Warum nach einer versteckten API suchen, wenn HTML bereits geparst wird

Fast jede moderne Schnittstelle – React, Vue, Angular, Next.js – lädt zunächst das Gerüst der Seite und zieht die Daten über separate Anfragen an eigene Endpunkte. Diese Endpunkte sind nicht dokumentiert, existieren aber, antworten mit reinem JSON und sind ohne Headless-Browser zugänglich.

Was Sie erhalten, wenn Sie zu ihnen wechseln:

• Der Traffic sinkt um das Zehnfache. Bei der Analyse einer typischen Produktanzeige wiegt die HTML-Seite etwa 400 KB zusammen mit Markup, Stilen und Trackern, während der entsprechende JSON-Endpunkt etwa 8 KB wiegt, wobei es darin mehr Felder gibt: interne IDs, Bestände, Produktvarianten.
• Kein Browser erforderlich. Das Rendering von JavaScript entfällt, und damit auch der Speicher, die CPU und Dutzende zusätzlicher Anfragen für Schriftarten und Analysen.
• Daten sind bereits strukturiert. Keine Selektoren, die durch Änderungen der CSS-Klasse brechen.
• Weniger Anfragen – weniger Gründe für ein Verbot. Das Rendern einer Katalogseite im Browser bedeutet Dutzende Anfragen an die Website; das gleiche Datenvolumen über die API – eine.

Für ein Projekt mit residenten Proxys ist dies eine direkte Einsparung: Die Tarife werden nach Gigabyte berechnet, und der Wechsel vom Rendering zu JSON reduziert die Rechnung normalerweise stärker als jede Art von Tricks zur Blockierung von Bildern. Ein verwandtes Thema ist wie man den Parser-Traffic um das 5-fache reduziert mit anderen Methoden.

Schritt für Schritt: Wie man den Endpunkt findet

1. Überprüfen Sie zunächst, ob es eine offizielle API gibt. Schauen Sie auf /developers, /api, /docs der Zielwebsite. Eine öffentliche dokumentierte API hat Versionierung und warnt vor Deprecations – eine private ändert sich stillschweigend.
2. Öffnen Sie die DevTools (F12) und gehen Sie zum Tab Netzwerk, wobei Sie sicherstellen, dass die Aufzeichnung aktiviert ist.
3. Aktivieren Sie den Filter Fetch/XHR. Dieser filtert Bilder, Schriftarten und Analysen heraus und lässt nur Anfragen nach Daten übrig.
4. Leeren Sie die Liste, um den Lärm der anfänglichen Ladezeit zu entfernen.
5. Provokation der benötigten Daten: Scrollen Sie durch die Ergebnisse, klicken Sie auf „nächste Seite“, wenden Sie einen Filter an, öffnen Sie eine Produktkarte. Die Anfrage, die Sie interessiert, erscheint im Moment der Aktion.
6. Finden Sie die Antwort mit Ihren Daten. Der schnellste Weg ist Ctrl+F im Netzwerk-Panel: Suchen Sie nach einem einzigartigen Wert, den Sie auf dem Bildschirm sehen (Artikelnummer, exakter Preis, Teil des Namens), und sehen Sie, welche Anfrage ihn erzeugt hat.
7. Kopieren Sie die Anfrage vollständig: Rechtsklick auf die Zeile → Kopieren → Als cURL kopieren. Konvertieren Sie dann den Code über curlconverter – so verlieren Sie keinen Header.

Charakteristische Pfade, auf die man zuerst achten sollte: /api/, /v1/, /v2/, /search, /products, /listings, /graphql.

Besonderer Fall: Websites auf Next.js

Hier erfordern die Daten oft überhaupt keine separate Anfrage – sie liegen direkt im HTML. Im alten Pages Router ist es der Block __NEXT_DATA__. Im App Router (Next.js 13 und neuer) sind die Daten für die Hydratation über Aufrufe von self.__next_f.push() in mehreren Script-Knoten verteilt – das ist der serialisierte Payload von React Server Components. Es ist unangenehm, ihn von Hand zu analysieren: Chunks verweisen über $-Präfixe aufeinander und können mitten im String geschnitten werden. Für Python gibt es die Bibliothek nextflight, die sowohl den Flight-Payload aus HTML als auch die rohe RSC-Antwort (Anfrage mit dem Header RSC: 1) analysiert und vorschlägt, darin nach Schlüsselnamen und nicht nach Array-Indizes zu suchen – so überlebt der Parser das Redeployment der Website.

Reverse Parameters: Pagination und Filter

Der gefundene Endpunkt ist fast immer parametrisiert. Es gibt drei Schemas:

• Nach Seiten: ?page=3&per_page=20
• Offset und Limit: ?offset=40&limit=20
• Cursor: ?after=<token>&limit=20 – der Token der nächsten Seite kommt im Body der vorherigen Antwort

Drei Regeln, die Stunden der Fehlersuche sparen:

• Hören Sie bei einem leeren Batch auf, und nicht bei einer im Voraus berechneten Seitenzahl: Der Zähler total in privaten APIs lügt häufiger, als man möchte.
• Überprüfen Sie die tatsächliche Batch-Größe. Wenn Sie 100 angefordert haben und 20 erhalten haben, hat der Endpunkt ein eigenes Limit, und Ihre Seitenarithmetik ist bereits falsch.
• Gehen Sie nicht auf Seite 500. Tiefe Pagination wird fast überall vom Server abgeschnitten; stattdessen schneiden Sie die Auswahl mit Filtern – nach Kategorie, Preisbereich, Datum.

Warum cURL aus dem Browser funktioniert, Ihr Code jedoch nicht

Dies ist der häufigste Punkt des Scheiterns, und der Grund ist fast immer derselbe: verlorener Header. Der kopierte cURL trägt den gesamten Kontext der Anfrage, während der selbstgeschriebene Client dies nicht tut.

Was normalerweise erforderlich ist:

• Benutzerdefinierte Header mit dem Präfix X- – X-CSRF-Token, X-Requested-With: XMLHttpRequest und alle möglichen X-*-Token, die das Frontend selbst einfügt. Ohne sie erhalten Sie eine Antwort im Bereich von 400–500.
• Referer – ein kontextueller Header, der durch die Aktion des Benutzers generiert wird. Viele Endpunkte überprüfen, ob die Anfrage „von ihrer Seite“ kam.
• Authorization: Bearer <JWT> – ein kurzlebiger Token, normalerweise für 15–60 Minuten. Es macht keinen Sinn, ihn fest zu codieren: Sie müssen in der Lage sein, einen frischen zu erhalten.
• Sitzungs-Cookies – halten Sie sie in einem Sitzungsobjekt und kopieren Sie sie nicht manuell.
• Korrekter Content-Type für POST: application/json und application/x-www-form-urlencoded kodieren den Body unterschiedlich, und eine Diskrepanz mit dem deklarierten Typ bricht die Anfrage stillschweigend.

Wo man die Tokens suchen kann, wenn sie nicht in Cookies sind: im HTML-Quellcode innerhalb von <script> (Suche nach einem bekannten Wert über Ctrl+F), in JavaScript-Bundles, im localStorage oder IndexedDB – Tab Anwendung in den DevTools.

Unterwasserfallen, von denen man spät erfährt

Die private API ändert sich ohne Vorwarnung. Sie hat keine Versionierung, keine Kompatibilitätsversprechen und keinen Support: Das Frontend-Team benennt ein Feld am Donnerstagabend um, und Ihr Parser sammelt Leere. Der Schutz besteht nicht aus einem „zuverlässigen Selektor“, sondern aus der Kontrolle der Struktur: Überprüfen Sie, ob die erforderlichen Felder vorhanden und vom richtigen Typ sind; überwachen Sie den Anteil leerer Werte und die Anzahl der Datensätze im Durchlauf; überspringen Sie fehlerhafte Datensätze, aber schlagen Sie Alarm, wenn der Ausschuss 10 % überschreitet; speichern Sie rohe Antworten, um später einen Vergleich zu haben.

Die API ist manchmal strenger geschützt als die Seite. Das kommt regelmäßig vor: HTML wird ruhig ausgegeben, während auf /api/ ein Anti-Bot hängt, der sowohl den TLS-Fingerabdruck als auch die Kombination der Header überprüft. Dann wird die Einsparung an Traffic durch einen Anstieg der Anzahl der fehlgeschlagenen Anfragen aufgezehrt, und der Gewinn wird aufgezehrt.

Signierte Anfragen. Wenn in den Parametern etwas wie sign, hash oder _s sichtbar ist, berechnet das Frontend die Signatur in JavaScript. Sie zu reproduzieren, ist ein separates Projekt, und oft ist es günstiger, bei HTML zu bleiben.

Frequenzbeschränkungen. Private Endpunkte sind nicht für einen Strom ausgelegt: Halten Sie 1–2 Anfragen pro Sekunde, setzen Sie separate Timeouts für Verbindung und Lesen (zum Beispiel 5 und 30 Sekunden), wiederholen Sie nur transiente Fehler – 429, 500, 502, 503, 504 – und berühren Sie nicht 401 und 404. Exponentielle Verzögerung mit Jitter ist obligatorisch, sonst gehen alle Worker gleichzeitig in die zweite Runde. Weitere Informationen finden Sie in der Analyse von Timeouts und Retry-Logik für Proxys.

Rechtlicher Rahmen. Öffentliche nicht-authentifizierte Endpunkte sind eine Situation, der Zugang zum Konto ist grundsätzlich eine andere: Die Registrierung bedeutet die Annahme der Nutzungsbedingungen. Persönliche Daten fallen unabhängig davon unter die DSGVO, wie leicht sie zu beschaffen sind. Fakten – Preise, Eigenschaften, Verfügbarkeit – sind nicht urheberrechtlich geschützt, im Gegensatz zu Texten und Bildern.

Wann man bei HTML bleiben sollte

Eine versteckte API ist nicht immer vorteilhaft. Bleiben Sie bei der Analyse von Seiten, wenn:

• die Website serverseitig ist und es einfach keine interne API gibt;
• der Endpunkt eine Signatur oder Token-Rotation erfordert – ihn zu unterstützen ist teurer als die Seite;
• auf der API ein strengerer Schutz besteht als auf den öffentlichen Seiten;
• Sie genau das Endergebnis benötigen, das das Frontend aus mehreren Quellen zusammenstellt;
• Sie Dutzende von Websites betreiben: Eine einheitliche HTML-Pipeline lässt sich besser skalieren als ein Zoo privater APIs mit individuellen Eigenheiten.

Welchen Typ von Proxys für API-Parsing wählen

Der Übergang zu JSON ändert die Berechnung, da der Engpass verschoben wird: Der Traffic wird gering, während die Anforderungen an die IP-Qualität und die Stabilität der Sitzung steigen.

• Offener Endpunkt ohne Authentifizierung und ohne Anti-Bot. Hier genügen Rechenzentrums-Proxys: Das Datenvolumen ist gering, es ist nicht nötig, für residente zu bezahlen.
• Endpunkt hinter einem Anti-Bot oder mit Sitzungsbindung. Benötigen Sie residente Proxys mit fester Sitzung: Token, Cookies und IP müssen während der gesamten Kette übereinstimmen, sonst setzt der Server die Sitzung bei der zweiten Anfrage zurück. Dabei bleibt die Rechnung bescheiden – Gigabytes im JSON-Modus werden langsam verbraucht.
• Daten aus einer mobilen Anwendung. Wenn die Webversion geschlossen ist und die Anwendung dasselbe einfacher ausgibt, werden die Endpunkte durch Traffic-Intercept gesucht – dies ist ein separater Prozess, der im Artikel über die Suche nach versteckten APIs in mobilen Anwendungen über mitmproxy behandelt wird.

Kurz gesagt

Zwanzig Minuten in den DevTools ersetzen oft Tage des Kampfes mit einem Headless-Browser: Filter Fetch/XHR, Suche nach sichtbarem Wert, Copy as cURL – und Sie haben eine funktionierende Anfrage in der Hand. Danach entscheiden die Details: Alle Header übertragen, das Schema der Pagination analysieren, Antwortvalidierung einfügen und nüchtern bewerten, ob der Endpunkt strenger geschützt ist als die Seite selbst. Wo die private API funktioniert, reduziert sie sowohl das Datenvolumen als auch die Anzahl der Anfragen – das heißt, sowohl die Kosten für Proxys als auch die Wahrscheinlichkeit eines Verbots.