Was ist neu
Der /api/auto endpoint ist jetzt der kürzeste Weg zu einer funktionierenden response für jede URL. Richte ihn auf ein Ziel. Auto entscheidet, ob der request über Single, Proxy Finder oder Browser läuft, bewältigt Anti-Bot-Challenges, wenn es auf eine trifft, und gibt eine Session zurück, die dein nächster Aufruf wiederverwenden kann.
Ein endpoint. Jedes Ziel. Kein Moduswechsel von deiner Seite.
Das ist die ganze Idee. Der Rest dieses Beitrags erklärt, wie es funktioniert, was es kostet und wo die Tücken liegen.
Wie es funktioniert
Unter Auto verbirgt sich eine Leiter von Stufen (günstig zuerst, teuer zuletzt). Bei jedem request steigt Auto die Leiter hinauf, bis eine Stufe eine response liefert, die deine validate Regeln akzeptieren.
Die Stufen der Reihe nach:
- Cached Session. Wenn Auto eine warme Session für diesen Host aus einem vorherigen Aufruf hat, wird sie zuerst genutzt. Der günstigste Weg.
- Proxy Finder. Ein rotierter proxy request. Gut für Sites, die hauptsächlich durch IP-Reputation geschützt sind.
- Browser. Ein vollständiger Render, der JavaScript ausführt, Anti-Bot-Challenges löst und die cookies sammelt, die die Site ausgibt.
Sobald eine Stufe gewinnt, speichert Auto die gefundene Session: die verwendete Proxy-ID, die von der Site ausgegebenen cookies und den User-Agent. Beim nächsten Aufruf desselben Hosts probiert Auto diese Session zuerst aus. Wenn sie noch funktioniert, zahlst du die günstige Stufe, nicht die teure.
Ein minimaler Aufruf:
curl -X POST "https://api.foura.ai/api/auto" \
-H "Authorization: Bearer pk_live_..." \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/data",
"validate": { "status": { "accept": [200] } }
}'
Eine gekürzte Antwort:
{
"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 für deinen nächsten Schritt. meta.rung zeigt, welcher Pfad gewonnen hat. session ist das Tripel für deinen /api/single Aufruf, um denselben Exit selbst zu wiederholen. Das Feld proxy ist eine opaque base36-ID (keine rohen IPs). Du kannst sie sicher loggen und zwischen Systemen weitergeben.
Auswirkungen
Zwei Zahlen sind hier wichtig.
Der erste Aufruf einer geschützten Seite durchläuft die Browser-Stufe: rendern, lösen, Cookies sammeln, die Seite an dich übergeben. Das kostet etwa 10 Credits. Sobald Auto eine funktionierende Session für diesen Host gecacht hat, laufen Folgeaufrufe über Single für 2 Credits. Der zweite Aufruf ist also fünfmal günstiger als der erste. Jeder weitere kostet den günstigen Tarif, solange die Session hält. Wir haben das beim Rollout in Prod gemessen: No-Cookie-Exits (sobald gefunden) kosten beim Replay genau 2 Credits pro Aufruf. Zuvor kosteten sie 10, als jeder Request durch den Proxy Finder ging.
Die zweite Zahl: Fehlgeschlagene Stufen werden nicht berechnet. Wenn Auto drei Proxys probiert und jeder einen 403 liefert, bevor der vierte erfolgreich ist, zählen nur die Credits des vierten. Du zahlst für gelieferten Content, nicht für die Suche.
Das ist der eigentliche Mehrwert. Die teure Stufe läuft einmal, die günstige Stufe danach immer wieder, und du musst die Caching-Logik nicht selbst schreiben.
Zwei weitere Verhaltensweisen sind erwähnenswert, da sie echte Probleme in Produktion lösen:
Geo-fenced Targets verschwenden keine Exits mehr. Wenn eine Seite für die meisten Exits 451 (oder ein Interstitial wegen rechtlicher Blockaden) zurückgibt, lernt Auto, welche Länder tatsächlich Content geliefert haben. Beim nächsten Aufruf zieht es zuerst frische Exits aus diesen Ländern und verteilt die gleichzeitige Last darauf. So wird ein einzelner funktionierender Exit nicht überlastet und ins Rate Limit getrieben.
Validate läuft auf jeder Stufe. Eine Seite mit falschem Content (ein Geo-Block, der Status 200 mit einem rechtlichen Hinweis als Body zurückgibt) zählt nie als Treffer. Wenn dein validate.data.fail "legal reasons" lautet, arbeitet Auto weiter, bis eine Stufe dies besteht. Nicht die gecachte Stufe. Nicht irgendeine Stufe. Wenn nichts durchgeht, erhältst du einen ehrlichen Fehlschlag mit dem wahren Grund.
Für Power User
Ein paar Stellschrauben, die wichtig werden, wenn du viel Volumen durch Auto schleust.
timeout_ms ist ein Budget für die gesamte Operation, nicht pro Stufe. Der Standardwert ist 120 Sekunden. Auto teilt es auf: Jeder Teilaufruf erhält das Minimum aus seinem natürlichen Timeout und dem restlichen Budget. Die Leiter startet keine neuen Stufen mehr, sobald zu wenig Zeit übrig ist. Setze 20.000 für interaktive Latenzarbeiten. Lass den Standardwert für Bulk-Crawls, die längere Tails tolerieren.
forceProxy ist standardmäßig aktiviert. Auto berührt das Ziel nie von der Ursprungs-IP von FourA aus, es sei denn, du setzt forceProxy: false. Ein Vorbehalt: Einige Seiten (interaktives Cloudflare mit IP-Trust-Gating) funktionieren von einer sauberen Rechenzentrums-IP aus tatsächlich besser als von einem Residential-Exit mit geringem Trust. Daher kann forceProxy: false bestimmte Ziele einfacher machen, nicht schwerer. Wenn du bei einem bestimmten Host wiederholt Challenges siehst, ist es einen Versuch wert, dies zu deaktivieren.
ignoreProxies ist eine Ausschlussliste für Clients. Übergib Proxy-IDs, von denen du weißt, dass sie verbrannt sind (aus einem vorherigen session.proxy, das bei dir ein Rate Limit erreicht hat), und Auto überspringt sie überall: bei der Wiederverwendung warmer Sessions, der Exit-Suche und dem Sub-Call an den Proxy Finder. So wählt Auto nicht erneut den Exit, den es laut dir vermeiden soll.
meta ermöglicht es dir auch, eigene Dashboards aufzubauen: Welche Hosts haben heute die Browser-Stufe erreicht, durchschnittliche Versuche pro Zustellung, Verhältnis von abgerufenen gelösten Challenges zu sauberen Fetches. Wenn ein bestimmter Host plötzlich von 2 auf 10 Credits steigt, ist das ein Signal für Session-Zerfall, auf das du reagieren kannst, bevor deine Rechnung steigt.
Ein Beispiel, das alle vier kombiniert:
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"Authorization": "Bearer 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"])
Für das validate Schema selbst findest du die frühere Anleitung unter Validierungsregeln entscheiden jetzt, was als Erfolg zählt.
Wie es weitergeht
Zwei Dinge stehen aktuell für Auto auf der Roadmap.
Session Inspection landet als Nächstes im Dashboard. Aktuell leben die Sessions, die Auto pro Host hält, innerhalb des Dienstes, und es gibt nichts zu sehen, wenn du auf deiner Seite debuggst. Wir bauen eine Session-Ansicht pro Host. Damit kannst du gecachte Sessions, ihr Alter, ihre Lebensdauer und die Rung-Historie dahinter sehen. Dazu kommt ein Button, um eine Session manuell zu löschen, wenn sich dein Target ändert und du weißt, dass der Cache falsch ist.
Danach folgen strengere Kostenkontrollen. Ein hartes Credit-Limit pro Request (gib nie mehr als X für diesen Call aus, schlage ehrlich fehl, wenn es passiert) und ein "single-only" Modus für Teams, deren Targets den Browser-Rung nie brauchen. Beides ist heute noch hinter Flags.
Der Sinn von Auto ist, dass du nicht darüber nachdenkst, welches Produkt du aufrufst. Das bedeutet nicht, dass du nicht inspizieren kannst, was passiert ist. Jede Response liefert den genutzten Rung und die erstellte Session mit. Lies diese beiden Felder aus und du weißt genau, warum deine Calls das kosten, was sie kosten.