Playground

Mit dem Playground (Seitenleiste > Playground) kannst du Live-API-Requests mit deinem echten Key ausführen, ohne Code zu schreiben. Es ist der schnellste Weg, eine neue Zielseite zu testen, eine knifflige Response zu debuggen oder Auto, Single, Proxy und Browser direkt miteinander zu vergleichen.

Öffne ihn unter foura.ai/dashboard#playground.

Funktionen

Ein Formular. Vier Engines. Echter Traffic.

Auto: Smart Fetch. Du übergibst eine URL samt validate-Regel und FourA wählt den günstigsten funktionierenden Pfad.
Single: Direkter HTTP-Fetch mit realistischen, browserähnlichen Wire-Eigenschaften
Proxy: Verwalteter Fetch mit rotierenden Proxys, optional beschränkt auf zielrelevante Länder
Browser: Öffnet die URL in einer Chrome-Browser-Instanz für JS-gerenderte Websites

Requests laufen über den API-Key, den du oben auf der Seite auswählst. Die Nutzung wird wie ein regulärer Production-Call auf das Kontingent dieses Keys angerechnet; achte also darauf, dein Kontingent beim Testen nicht aufzubrauchen.

Key auswählen

Das API-Key-Dropdown listet jeden aktiven Key auf, den du nutzen kannst: deine eigenen unter My Keys, danach eine Gruppe pro Organisation, der du angehörst. Jedes Mitglied kann den Key einer Organisation ausführen, und ein Request darüber wird auf das Kontingent des Organisationseigentümers angerechnet. Wähle den Key aus, über den der Request abgerechnet werden soll. Wenn du noch keine aktiven Keys hast, führt dich ein direkter Link zur Seite API Keys, um einen zu erstellen.

Modus auswählen

Eine obere Mode-Zeile schaltet zwischen Auto und den manuellen Engines um. Wenn Auto ausgewählt ist, wechselt das Formular zur reduzierten Auto-Oberfläche (URL plus validate plus einige Optionen). Beide Zeilen werden immer angezeigt: Mode: Auto und Product: Single, Proxy, Browser. Die Auswahl des einen hebt die Auswahl des anderen auf. Das Wechseln der Produkte ändert die sichtbaren Felder und bestimmt, welche Engine der Request anspricht. Die aktuelle Auswahl bleibt beim Neuladen der Seite erhalten.

Mode	Wann zu verwenden
Auto	Neues Ziel oder Website mit gemischten Schutzmechanismen. Auto wählt den günstigsten Pfad und merkt sich, was funktioniert.
Single	Schneller HTTP-Fetch. Beste erste Wahl für einen bekannten Host.
Proxy	Gleicher Fetch mit automatischer Proxy-Rotation. Setze `exitCountries`, wenn du ein zielrelevantes Land benötigst.
Browser	Lädt die Seite in einer Chrome-Browser-Instanz. Verwende dies, wenn Daten erst nach Ausführung von JavaScript erscheinen.

Request zusammenstellen

URL-Zeile

Die oberste Zeile enthält die HTTP-Methode (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), die Ziel-URL und den Send-Button. Single, Proxy und Auto unterstützen jede Methode. Browser ignoriert die Methode (Chrome führt für die Navigation immer GET aus) und den Body.

Request-Tabs

Unter der URL-Zeile kannst du über fünf Tabs alle weiteren Angaben festlegen:

Tab	Gesteuerte Optionen
UI	Formularfelder für Timeouts, Redirects, Flags, Proxy, browserspezifische Optionen und Validate-Regeln
Body	Freitext-Body für POST- / PUT- / PATCH-Requests
Headers	Benutzerdefinierte Request-Header als Key-Value-Paare
Cookies	Mit dem Request zu sendende Cookies
Raw	Die exakte JSON-Payload, die gesendet wird, als schreibgeschützte Vorschau mit JSON kopieren und dem curl-Befehl darunter

Alles, was du in UI / Body / Headers / Cookies änderst, wird direkt in Raw übernommen. Du kannst nicht direkt in Raw tippen: Bearbeite den Request in den anderen Tabs. Ein roter Punkt markiert jeden Tab und jeden einklappbaren Bereich, der vom Standardwert der Engine abweicht. So siehst du sofort, was du angepasst hast.

Bereiche des UI-Tabs

Der UI-Tab unterteilt Einstellungen in einklappbare Bereiche. Leere Felder nutzen den Schema-Standard der Engine. Bereiche, die für den aktuellen Modus nicht gelten, werden ausgeblendet.

Timeouts: timeout_ms, connect_timeout_ms, accept_timeout_ms, server_response_timeout_ms, dns_cache_timeout_sec. Auto zeigt nur timeout_ms (das Gesamtbudget).
Redirects: Aktivieren und followRedirects (0 bis 20) setzen. Für Single und Proxy. Browser folgt Redirects automatisch.
Flags: unblocker für Single, Proxy und Browser (unblocker im Browser führt die von der Seite geforderten Checks aus); tryJsonData und returnBuffer für Single und Proxy. Auto zeigt stattdessen forceProxy und returnSession.
Proxy: Wähle eine bestimmte Proxy-ID für Single oder Browser, oder setze maxTries, den äußeren Proxy-Timeout, exitCountries, exitClass und ignoreProxies für die Proxy-Engine. Auto zeigt zusätzlich ignoreProxies. Das Auswahlfeld exitClass hat drei Zustände: Nicht gesetzt sendet kein Feld, standard verhindert jede Eskalation und premium erlaubt die Eskalation auf Premium-Exits, wenn der Standard-Pool überlastet ist. Nicht gesetzt und standard sind unterschiedliche Requests; lass das Feld daher leer, wenn du keinen der beiden Werte explizit setzen willst. Premium erfordert einen Plan mit Premium-Exits: siehe exitClass.
Browser-Profil: Drei kaskadierende Dropdowns (os, browser und version), die verfügbare FourA-Profile listen. Sie erscheinen in den Modi Single und Proxy. Lass sie leer für das neueste Chrome. Jedes Dropdown schränkt die anderen beiden ein, sodass ungültige Kombinationen gar nicht erst entstehen. Dieser Bereich setzt unblocker voraus: Ist die Option deaktiviert, werden keine Browser-Header gesendet, das Profil würde nur unvollständig greifen und die API lehnt den Request ab.
Browser: Reine Browser-Optionen wie checkStatus und checkText.
Validate: status accept und status fail akzeptieren kommagetrennte Statuscodes (validate.status), während body accept und body fail Substrings mit durch | getrennten Alternativen akzeptieren (validate.data). Verfügbar für Single, Proxy und Auto. Browser nutzt stattdessen checkStatus und checkText. Das Formular enthält kein Feld für Header-Regeln (validate.headers).

Sobald ein Durchlauf einen funktionierenden Proxy zurückgibt, erscheint der Bereich Working proxies am Ende des UI-Tabs. Er listet bis zu 20 Proxy-IDs auf, die neuesten zuerst, jeweils mit Exit-Land und Uhrzeit. use fügt einen in das Feld proxy unter Single oder Browser ein (die Proxy-Engine sucht sich selbst einen), und × entfernt ihn aus der Liste.

Exit-Länder eingrenzen (Proxy-Modus)

Das Feld exitCountries unter Proxy akzeptiert eine kommagetrennte Liste zweistelliger Ländercodes (CZ, GB). Die Werte werden beim Absenden getrimmt, in Großbuchstaben umgewandelt und dedupliziert. Die Auswahl erfolgt über eine strikte Allowlist: Proxies mit unbekanntem Exit werden ausgeschlossen und der Request weicht niemals auf ein anderes Land aus. Wenn der aktuelle Pool keine Treffer enthält, liefert die Response code: "no_eligible_proxy" zurück, wobei der angeforderte Scope in details.exitCountries widergespiegelt wird. Behalte den Scope bei und versuche es später erneut.

Wenn ein Proxy-Aufruf mit Scoping erfolgreich ist, zeigt die Response-Leiste exit <CODE> neben der Proxy-ID an, damit du prüfen kannst, ob das bereitgestellte Land deiner Anfrage entspricht.

Die Schaltfläche Reset in der Toolbar (neben History und Saved) setzt den Playground vollständig zurück. Da dies destruktiv ist, öffnet sich ein Bestätigungsdialog mit einer genauen Auflistung aller gelöschten Elemente: alle drei Produktformulare (Single, Proxy, Browser), alle gespeicherten Cookies im Jar, alle übertragenen Proxies sowie die aktuelle Response. Gespeicherte Presets und der ausgewählte API-Key bleiben erhalten. Klicke auf Reset everything, um zu bestätigen; jede andere Aktion bricht ab.

Senden und Abbrechen

Klicke auf Send, um den Request auszuführen. Die rechte Spalte wechselt während des aktiven Aufrufs in einen Ladezustand mit Spinner und einem Cancel-Button. Klicke auf Cancel (oder tippe auf Mobilgeräten erneut auf die Schaltfläche), um abzubrechen. Ein abgebrochener Request stellt den Idle-Platzhalter mit "Request canceled." wieder her, anstatt einen Fehler anzuzeigen.

Die Response-Karte wechselt zum Ergebnis, sobald der Request abgeschlossen ist (oder fehlschlägt). Auto-Durchläufe können länger dauern als die manuellen Engines, da die Ladder bei einem Cold-Target mehrere Stufen durchlaufen kann.

Response analysieren

Die Response-Spalte spiegelt das Request-Layout mit eigenen Tabs wider:

Tab	Was angezeigt wird
Body	Geparster Body. Wechselt je nach Rückgabe zwischen den Ansichten JSON, HTML und Text.
Headers	Response-Header, eine Zeile pro Eintrag.
Cookies	Vom Ziel zurückgegebene Cookies, sowohl in geparster (nach Host gruppiert) als auch in Raw-Ansicht (Set-Cookie-Text). Die geparste Ansicht zeigt ein `HO`-Badge bei Host-only-Cookies; Domain-Cookies sind unmarkiert.
Raw	Der vollständige von der API zurückgegebene JSON-Envelope.

Die Response-Toolbar bietet Copy und Download für die gesamte Response sowie Find in response (Strg+K oder Cmd+K), um den geöffneten Tab zu durchsuchen, wobei du mit Enter und Shift+Enter durch die Treffer navigieren kannst. Body, Headers und Cookies verfügen zudem über eigene Copy- und Download-Optionen für den jeweiligen Tab.

Eine Metaleiste über den Tabs zeigt den Upstream-HTTP-Status, die Gesamtzeit, die Proxy-ID, die den Aufruf verarbeitet hat, und (bei einem Proxy-Aufruf mit Scope) den zweistelligen exit <CODE>. Bei Auto-Ausführungen zeigt die Leiste außerdem, welche Stufe die Response geliefert hat, wie viele Teilversuche unternommen wurden und welche Credits verbraucht wurden.

Was der Aufruf benötigt hat

Ein Satz unter der Metaleiste beschreibt in Worten, wie die Seite übertragen wurde. Bei einem Auto-Durchlauf nennt er die Stufe (eine Session, die FourA bereits für den Host hatte, ein einfacher Request, ein rotierender Proxy, ein echter Browser oder erst ein Browser und dann ein günstiger Replay), ob eine Challenge gelöst wurde, wie viele Versuche nötig waren und was es gekostet hat.

Wenn ein Limit deines Tarifs den Aufruf abgelehnt hat, weist der Satz zuerst darauf hin: "Stopped by your plan, not by the site", gefolgt vom jeweiligen Limit (heutige Browser-Requests aufgebraucht, zu viele gleichzeitige Requests, Credits dieses Zeitraums aufgebraucht usw.) und einem Link zu Usage & Limits. Die Zeile basiert auf dem X-FourA-Limit-Code, den die API zurückgegeben hat. So erkennst du bei einer fehlschlagenden Seite direkt, ob die Website oder dein Tarif der Grund war.

Werte zwischen Durchläufen übertragen

Nach jedem Durchlauf, der wiederverwendbare Session-Daten zurückgegeben hat, zeigt ein kleines Carry-Bedienelement in der Response-Symbolleiste an, was verfügbar ist:

Auto-Durchläufe bieten das vollständige session-Trio (proxy, cookies, userAgent).
Browser-Durchläufe bieten die Response-userAgent sowie die Proxy-ID, falls eine verwendet wurde.
Proxy-Durchläufe bieten die zurückgegebene Proxy-ID, das Browser-Profil, falls die Rotation eines gewählt hat, das du nicht angefordert hast, und die exitClass, die den Aufruf bedient hat, damit eine Premium-Antwort direkt zurückgesendet werden kann.

Klicke auf Carry und wähle mit einem Klick aus, wo die einzelnen Werte angewendet werden sollen: userAgent wird zu einem User-Agent-Header bei Single oder Proxy, und die Proxy-ID wird in das proxy-Feld bei Single oder Browser eingefügt. Felder, die einen übertragenen Wert erhalten, zeigen den roten "Geändert"-Punkt an, damit du siehst, was angepasst wurde.

Ein übertragenes Browser-Profil füllt die drei Auswahllisten für OS, Browser und Version aus und aktiviert unblocker; dieselbe Regel gilt, wenn du ein Profil manuell auswählst. Es wird erst angeboten, sobald der Profilkatalog geladen ist, da das Formular aus drei Dropdowns und nicht aus einem ID-Feld besteht.

Das Profil ist der einzige Wert, der anzeigt, dass der Request, der funktioniert hat, nicht der von dir eingegebene Request war: Proxy meldet profile nur, wenn zu einer Browser-Familie gewechselt wurde, die du nicht angefordert hast. Ein Replay ohne diesen Wert wiederholt die Version, die fehlgeschlagen ist. Siehe Why a Proxy Request Ran Out of Tries.

Auf Vollbild vergrößern

Das Vergrößern-Symbol in der Response-Symbolleiste hebt die Response-Karte aus dem geteilten Layout in ein Vollbild-Overlay. Nutze es für tiefe JSON-Bäume, lange Set-Cookie-Dumps oder breite HTML-Bodies, bei denen die Spalte mit halber Breite zu eng wird. Das Scrollen der Seite selbst wird pausiert, während das Overlay geöffnet ist. Klicke erneut auf das Symbol (oder drücke Escape), um die Ansicht zu minimieren.

Der curl-Reproducer

Auf dem Raw-Tab des Requests zeigt ein curl-Block unter dem JSON das genaue Befehlszeilen-Äquivalent des Requests, den du gerade erstellst, zusammen mit einem Button Copy curl. Kopiere ihn, um den Request im Terminal zu reproduzieren, mit einem Teammitglied zu teilen oder in einen Bug-Report einzufügen.

Bei aufdeckbaren Keys fügt ein Button Reveal key neben dem Snippet den echten Plain-Text-Key direkt in den curl-Befehl ein, sodass du ihn direkt kopieren und ausführen kannst. Klicke erneut, um ihn wieder auszublenden. Legacy-Keys (die vor der Einführung des Reveal-Features erstellt wurden) behalten einen PASTE_PLAINTEXT_FOR_<key-name>-Platzhalter; generiere den Key auf der Seite API Keys neu, um ihn aufdeckbar zu machen.

Das Aufdecken wird jedes Mal auf dem Server auditiert, und der Klartext-Key bleibt nur für die aktuelle Seitensitzung im Speicher.

Presets speichern

Wenn du dasselbe Ziel wiederholt konfigurierst, speichere es. Klicke in der Zeile der Request-Tabs auf Save, um die aktuelle Konfiguration als benanntes Preset zu sichern.

Öffne Saved in der Toolbar, um deine Presets anzuzeigen. Klicke auf Load, um das Formular auszufüllen, oder auf Delete, um eines zu entfernen.

Ein Request, der aus dem DevTools-Tab der FourA Chrome-Extension geöffnet wird, lädt mit dem Key der Extension vorausgewählt, falls dieser Key zu deinem Account gehört, und die Seite weist darauf hin. Andernfalls wirst du aufgefordert, einen Key auszuwählen. Ein wiederholter Request, der unblocker nicht setzt, wird wie bei der API standardmäßig damit ausgeführt.

Preset-Feld	Gespeicherter Inhalt
Name	Ein kurzes Label (bis zu 100 Zeichen)
Description	Optionale Notizen (bis zu 500 Zeichen)
Endpoint	Für welche Engine das Preset bestimmt ist (auto / single / proxy / browser)
Config	Die vollständige Request-Payload inklusive UI-Feldern, Headern, Cookies und Body

Presets sind an deinen Benutzer-Account gebunden und werden nicht mit Teammitgliedern geteilt.

Aus dem Verlauf wiederholen

Jeder Request, den du ausführst, wird protokolliert. Öffne History in der Toolbar, um deine letzten 20 Ausführungen zu sehen, sortiert nach den neuesten zuerst.

Jede Zeile zeigt den Endpoint, die Ziel-URL, den Status und die Uhrzeit. Klicke in einer Zeile auf Replay, um diesen Request wieder in das Formular zu laden, und dann auf Send, um ihn erneut auszuführen.

Der Verlauf ist automatisch auf deinen Account beschränkt: Du siehst nur deine eigenen Ausführungen.

Aus Activity öffnen

Der Detail-Dialog im Activity Log enthält einen Button Open in Playground. Klicke darauf und der Playground lädt sowohl den archivierten Request als auch die archivierte Response. Das Formular wird mit der gespeicherten Payload ausgefüllt und die Response-Card zeigt an, was die API zu diesem Zeitpunkt zurückgegeben hat, mit einem "archived"-Badge in der Proxy-Meta-Leiste ("archived [, truncated] [, via ]").

Von dort aus kannst du einen Parameter ändern und auf Send klicken, um einen neuen Request an die Live-API zu senden, oder einfach die archivierte Payload prüfen, ohne sie erneut auszuführen. Payloads werden 24 Stunden lang aufbewahrt, daher haben ältere Activity-Zeilen keine neu ladbare Response.

Tipps

Starte im Playground, bevor du Code für ein neues Ziel schreibst. Mit aktiviertem Auto weißt du innerhalb von Sekunden, ob ein günstiger Fetch ausreicht oder die Seite ein Browser-Solve erzwingt.
Führe bei Zielen mit Ländersperre einen Proxy-Aufruf mit gesetztem exitCountries aus und übergib die zurückgegebene Proxy-ID an einen Browser-Aufruf, damit das JavaScript-Rendering über denselben Exit erfolgt.
Speichere ein Preset für jedes Ziel, das du regelmäßig scrapst. Das erneute Ausführen eines gespeicherten Presets dauert einen Klick; die Rekonstruktion des Requests aus dem Gedächtnis dauert länger.
Nutze den Tab Cookies, um sessionsbasiertes Scraping zu debuggen. Die rohe Set-Cookie-Ansicht zeigt genau, was das Ziel gesendet hat.
Wenn ein Ziel dich abweist, probiere einen anderen Eintrag in der Browser-Profile-Auswahl, bevor du zu einer schwereren Engine greifst. Der Wechsel des vorgegebenen Browsers ist kostenlos; ein Browser-Render nicht.
Playground-Requests werden über den ausgewählten Key abgerechnet. Verwende einen dedizierten Key mit niedrigem Kontingent für Tests, um die Produktionsnutzung sauber zu halten.