Alle Beiträge

Wir stellen Auto vor: Ein Endpoint für jedes Ziel

Der Auto-Endpoint wählt für jeden Request Single, Proxy Finder oder Browser, löst Anti-Bot-Challenges und liefert eine Session, die dein nächster Aufruf wiederverwenden kann.

Was neu ist

Der /api/auto-Endpoint ist jetzt der kürzeste Weg zu einer funktionierenden Response für jede URL. Übergib einfach ein Ziel. Auto entscheidet, ob der Request über Single, Proxy Finder oder Browser läuft, löst Anti-Bot-Challenges, sobald sie auftreten, und liefert eine Session zurück, die dein nächster Call wiederverwenden kann.

Ein Endpoint. Jedes Ziel. Kein manueller Moduswechsel auf deiner Seite.

Das ist das gesamte Prinzip. Der Rest dieses Beitrags erklärt, wie es funktioniert, was es kostet und wo die Haken liegen.

Funktionsweise

Hinter Auto steht eine Stufenleiter (günstig zuerst, teuer zuletzt). Bei jedem Request steigt Auto die Leiter hoch, bis eine Stufe eine Response liefert, die deine validate-Regeln akzeptieren.

Die Stufen in der Reihenfolge:

  1. Gecachte Session. Wenn Auto aus einem vorherigen Call eine aktive Session für diesen Host hat, wird diese zuerst wiederverwendet. Der günstigste Pfad.
  2. Proxy Finder. Ein rotierter Proxy-Request. Geeignet für Seiten, die primär über IP-Reputation geschützt sind.
  3. Browser. Ein vollständiges Rendering, das JavaScript ausführt, Anti-Bot-Challenges löst und die von der Seite gesetzten Cookies sammelt.

Sobald eine Stufe erfolgreich ist, speichert Auto die gefundene Session: die verwendete Proxy-ID, die Cookies der Seite und den User-Agent. Beim nächsten Call an denselben Host testet Auto diese Session zuerst. Funktioniert sie noch, zahlst du die günstige Stufe statt der teuren.

Ein minimaler Call:

curl -X POST "https://api.foura.ai/api/auto" \
  -H "X-API-Key: pk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/data",
    "validate": { "status": { "accept": [200] } }
  }'

Eine gekürzte Response:

{
  "status": 200,
  "data": "...",
  "headers": [...],
  "meta": {
    "rung": "cache",
    "solved": false,
    "attempts": 1,
    "credits": 2
  },
  "session": {
    "proxy": "CLN1B8",
    "cookies": [{ "name": "cf_clearance", "value": "..." }],
    "userAgent": "..."
  }
}

Zwei Felder sind wichtig fuer das, was du als Naechstes baust. meta.rung zeigt dir, welcher Pfad erfolgreich war. session ist das Tripel, das du in einen /api/single-Aufruf uebergeben kannst, um denselben Exit selbst erneut abzuspielen. Das Feld proxy ist eine opake Base36-ID (keine Roh-IPs), sicher zu loggen und sicher zwischen Systemen zu uebertragen.

Auswirkung

Zwei Zahlen spielen hier eine Rolle.

Der erste Aufruf einer geschuetzten Seite nutzt die Browser-Stufe: Rendern, Loesen, Cookies sammeln, Seite zurueckgeben. Das kostet etwa 10 Credits. Sobald Auto eine funktionierende Session fuer diesen Host zwischengespeichert hat, spielen nachfolgende Aufrufe diese erneut ab: ueber Single fuer 2 Credits oder ueber Proxy Finder fuer 4 Credits, wenn die Cookies der Session von jeder Adresse aus funktionieren. Der zweite Aufruf ist also bis zu 5-mal guenstiger als der erste, und jeder weitere bleibt bei der guenstigen Rate, solange die Session gueltig ist. Wir haben das beim Rollout in der Produktion gemessen: Cookie-freie Exits kosten nach dem Finden exakt 2 Credits pro Aufruf, statt der 10 Credits, die faellig wurden, als jeder Request ueber Proxy Finder lief.

Die zweite Zahl: Fehlgeschlagene Stufen werden nicht abgerechnet. Wenn Auto drei Proxys testet und jeder mit 403 fehlschlaegt, bevor der vierte liefert, zaehlen nur die Credits des vierten. Du zahlst fuer gelieferten Inhalt, nicht fuer die Suche.

Das ist der Kernwert. Die teure Stufe laeuft einmal, die guenstige Stufe laeuft danach dauerhaft, und du musst die Caching-Logik nicht selbst schreiben.

Zwei weitere Verhaltensweisen lohnen sich zu erwaehnen, da sie echte Probleme im Produktivbetrieb loesen:

Geo-blockierte Ziele verschwenden keine Exits mehr. Wenn eine Seite fuer die meisten Exits den Status 451 oder eine rechtliche Sperrseite zurueckgibt, lernt Auto, welche Laender tatsaechlich Inhalte geliefert haben. Beim naechsten Aufruf holt es zuerst frische Exits aus diesen Laendern und verteilt die gleichzeitige Last darauf. So wird ein einzelner funktionierender Exit nicht ueberlastet und ins Rate Limit getrieben.

Validate laeuft auf jeder Stufe. Eine Seite mit falschem Inhalt (ein Geo-Block, der Status 200 mit einem rechtlichen Hinweis im Body liefert) zaehlt nie als Treffer. Wenn dein validate.data.fail den Text "legal reasons" enthaelt, versucht Auto es weiter, bis eine Stufe den Check besteht. Nicht die gecachte Stufe. Keine Stufe. Wenn nichts durchkommt, erhaeltst du einen ehrlichen Fehler mit dem echten Grund.

Fuer Power-User

Einige Parameter, die wichtig werden, sobald du groesseres Volumen ueber Auto verarbeitest.

timeout_ms ist ein Budget fuer die gesamte Operation, nicht pro Stufe. Der Standardwert ist 120 Sekunden. Auto teilt es auf: Jeder Unteraufruf erhaelt das Minimum aus seinem natuerlichen Timeout und dem verbleibenden Budget, und die Kaskade startet keine neuen Stufen mehr, wenn zu wenig Zeit uebrig ist. Setze 20.000 fuer interaktive Latenzen. Behalte den Standardwert fuer Bulk-Crawls bei, die laengere Laufzeiten tolerieren.

forceProxy ist standardmaessig aktiv. Auto greift nie von der Ursprungs-IP von FourA auf das Ziel zu, es sei denn, du setzt forceProxy: false. Ein wichtiger Hinweis: Manche Seiten (interaktives Cloudflare mit IP-Trust-Pruefung) funktionieren ueber eine saubere Rechenzentrums-IP tatsaechlich besser als ueber einen Residential-Exit mit geringem Trust. Daher kann forceProxy: false bestimmte Ziele einfacher machen, nicht schwerer. Wenn du bei einem bestimmten Host wiederholt Challenges siehst, lohnt es sich, diese Option zu deaktivieren.

ignoreProxies ist eine clientseitige Avoid-Liste. Übergib Proxy-IDs, von denen du weißt, dass sie verbrannt sind (aus einem vorherigen session.proxy, das bei dir in ein Rate Limit gelaufen ist), und Auto überspringt sie überall: bei der Wiederverwendung warmer Sessions, bei der Exit-Suche und beim Sub-Call zu Proxy Finder. So wählt Auto denselben Exit nicht erneut aus, den du gerade ausgeschlossen hast.

meta ermöglicht es dir außerdem, eigene Dashboards darauf aufzubauen: welche Hosts heute die Browser-Stufe erreicht haben, durchschnittliche Versuche pro Zustellung, Verhältnis von Abrufen mit gelösten Challenges zu sauberen Abrufen. Wenn ein bestimmter Host plötzlich von 2 Credits auf 10 ansteigt, ist das ein Signal für Session-Verfall, auf das du reagieren kannst, bevor deine Rechnung ansteigt.

Ein Beispiel, das alle vier kombiniert:

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"X-API-Key": "pk_live_..."},
    json={
        "url": "https://example.com/product/9876",
        "timeout_ms": 30000,
        "forceProxy": True,
        "ignoreProxies": ["CLN1B8", "K7X9AB"],
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ['"price":'], "fail": ["captcha", "legal reasons"]}
        }
    }
).json()

# If Auto delivered, keep the session for the next call to this host
if r.get("status") == 200 and "session" in r:
    session = r["session"]                              # {proxy, cookies, userAgent}
    print(r["meta"]["rung"], r["meta"]["credits"], r["meta"]["attempts"])

Das Schema für validate findest du im früheren Walkthrough unter Validate Rules Now Decide What Counts as Success.

Was als Nächstes kommt

Zwei Dinge stehen aktuell auf der Roadmap für Auto.

Als Nächstes kommt die Session-Inspektion im Dashboard. Derzeit liegen die Sessions, die Auto pro Host verwaltet, intern im Service. Beim Debuggen von unerwartetem Verbrauch siehst du davon nichts. Wir bauen eine hostbasierte Session-Ansicht. Damit siehst du gecachte Sessions, ihr Alter, die verbleibende Lebensdauer und die Rung-Historie dahinter. Dazu kommt ein Button, um eine Session manuell zu verwerfen, wenn sich dein Ziel ändert und der Cache veraltet ist.

Danach folgen präzisere Kostenkontrollen. Ein striktes Credit-Limit pro Request (nie mehr als X für diesen Call ausgeben, sonst sauber fehlschlagen) und ein "single-only"-Modus für Teams, deren Targets den Browser-Rung nie benötigen. Beide Features liegen aktuell hinter Feature-Flags.

Auto nimmt dir die Entscheidung ab, welches Produkt du aufrufen musst. Trotzdem behältst du die volle Transparenz. Jede Response liefert den genutzten Rung und die erstellte Session mit. Anhand dieser zwei Felder siehst du genau, warum deine Calls wie viel kosten.