Playground

Der Playground (Seitenleiste > Playground) lässt dich Live-API-Requests mit deinem echten Key ausführen, ohne Code zu schreiben. Es ist der schnellste Weg, eine neue Zielseite auszuprobieren, eine schwierige Response zu debuggen oder Auto, Single, Proxy und Browser direkt zu vergleichen.

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

Was er tut

Ein Formular. Vier Engines. Echter Traffic.

Auto: Smart Fetch. Du übergibst eine URL plus eine validate-Regel und FourA wählt den günstigsten Weg, der funktioniert.
Single: Direkter HTTP Fetch mit realistischen, browserähnlichen Wire-Eigenschaften
Proxy: Verwalteter, rotierender Proxy Fetch, optional auf zielländerspezifische Standorte beschränkt
Browser: Öffnet die URL in einer Chrome-Browser-Instanz für JS-gerenderte Seiten

Requests laufen über den API-Key, den du oben auf der Seite auswählst. Die Nutzung wird vom Kontingent dieses Keys wie ein produktiver Aufruf abgezogen. Verbrauche also deinen Plan nicht beim Testen.

Key auswählen

Das API-Key-Dropdown zeigt jeden aktiven Key in deinem Bereich: persönliche Keys, Org-Keys, die du verwaltest, und für das Team freigegebene Keys, auf die du Zugriff hast. Wähle denjenigen aus, über den der Request abgerechnet werden soll. Wenn du noch keine aktiven Keys hast, verlinkt dich ein Inline-Prompt zur Seite API Keys, um einen zu erstellen.

Modus wählen

Eine obere Mode-Zeile wechselt zwischen Auto und den manuellen Engines. Wenn Auto ausgewählt ist, wechselt das Formular zur minimalen Auto-Oberfläche (URL plus validate sowie ein paar Einstellungen). Wenn du Auto deaktivierst, erscheinen drei Schaltflächen: Single, Proxy, Browser. Das Wechseln der Schaltflächen ändert, welche Felder sichtbar sind und welche Engine der Request nutzt. Die aktuelle Auswahl bleibt beim Neuladen der Seite erhalten.

Mode	Wann er genutzt wird
Auto	Neues Ziel oder Seite mit gemischtem Schutz. Auto wählt den günstigsten Weg 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 länderspezifisches Ziel benötigst.
Browser	Lädt die Seite in einer Chrome-Browser-Instanz. Nutzen, wenn Daten erst nach JavaScript-Ausführung erscheinen.

Request aufbauen

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 akzeptieren jede Methode. Browser ignoriert die Methode (Chrome führt bei der Navigation immer GET aus) und den Body.

Request-Tabs

Unter der URL-Zeile kannst du in fünf Tabs alles Weitere ausfüllen:

Tab	Was er steuert
UI	Formularfelder für Timeouts, Redirects, Flags, Proxy, browserspezifische Optionen und Validate-Regeln
Body	Freiform-Body für POST / PUT / PATCH Requests
Headers	Eigene Request-Header als Schlüssel-Wert-Paare
Cookies	Cookies, die mit dem Request gesendet werden
Raw	Der exakte JSON-Payload, der gesendet wird (direkt editierbar)

Was auch immer du in UI / Body / Headers / Cookies änderst, wird in Raw gespiegelt. Das Bearbeiten von Raw funktioniert ebenfalls, wobei die anderen Tabs entsprechend aktualisiert werden. Ein roter Punkt erscheint auf jedem Tab oder jedem einklappbaren Abschnitt, der einen Wert enthält, der von den Standardwerten der Engine abweicht, damit du auf einen Blick erkennen kannst, was du angepasst hast.

UI Pane Sections

Der UI-Tab gruppiert Einstellungen in einklappbare Abschnitte. Leere Felder greifen auf den Schema-Standard der Engine zurück. Abschnitte, die für den aktuellen Modus nicht zutreffen, werden ausgeblendet.

Timeouts: timeout_ms, connect_timeout_ms, accept_timeout_ms, server_response_timeout_ms, dns_cache_timeout_sec. Auto zeigt nur timeout_ms an (das Gesamtbudget).
Redirects: aktiviere und setze followRedirects (0-20). Single, Proxy, Auto. Der Browser folgt Weiterleitungen selbstständig.
Flags: unblocker für Single, Proxy und Browser (unblocker im Browser löst den Auto-Defense-Solver aus); tryJsonData und returnBuffer für Single und Proxy. Auto zeigt stattdessen forceProxy und returnSession an.
Proxy: Wähle eine spezifische Proxy-ID für Single oder Browser, oder setze maxTries, den Proxy Outer-Timeout, exitCountries und ignoreProxies für die Proxy-Engine. Auto zeigt außerdem ignoreProxies an.
Browser profile: Drei kaskadierende Dropdowns, os, browser und version, listen auf, was FourA tatsächlich präsentieren kann. Sie erscheinen im Single- und Proxy-Modus. Lass sie für das neueste Chrome leer. Jede Auswahl grenzt die anderen beiden ein, so dass eine Kombination, die zu nichts führt, nie erscheint. Der Abschnitt benötigt den aktivierten Web Unblocker: Wenn er ausgeschaltet ist, werden keine Browser-Header gesendet, ein Profil würde nur halb angewendet und die API lehnt die Anfrage stattdessen ab.
Browser: Nur-Browser-Optionen wie checkStatus und checkText.
Validate: validate.status (Statuscodes), validate.headers (Header-Key-Value-Regeln) und validate.data (Body Accept / Fail Teilstrings, durch | getrennte Alternativen) Accept / Fail-Regeln. Verfügbar für jeden Modus, einschließlich Auto.

Exit Country Scoping (Proxy Mode)

Das exitCountries-Feld auf dem Proxy akzeptiert eine durch Kommas getrennte Liste von zweistelligen zielseitig sichtbaren Ländercodes (CZ, GB). Werte werden beim Absenden getrimmt, in Großbuchstaben umgewandelt und dedupliziert. Die Auswahl ist eine strikte Allowlist: Proxys mit unbekannten Exits werden ausgeschlossen und die Anfrage fällt nie auf ein anderes Land zurück. Wenn der aktuelle Pool keine Übereinstimmung hat, liefert die Response code: "no_eligible_proxy" zurück, wobei der angeforderte Scope in details.exitCountries wiederholt wird. Bewahre den Scope auf und versuche es später noch einmal.

Wenn ein Proxy-Aufruf unter Scoping erfolgreich ist, zeigt der Response-Strip exit <CODE> neben der Proxy-ID an, damit du überprüfen kannst, ob das bediente Land mit dem von dir angeforderten übereinstimmt.

Die Schaltfläche Reset in der Symbolleiste (neben History und Saved) setzt den Playground vollständig zurück. Da dies destruktiv ist, öffnet sich ein Bestätigungsdialog, der auflistet, was genau gelöscht wird: alle drei Produktformulare (Single, Proxy, Browser), alle im Cookie-Jar gespeicherten Cookies, alle mitgenommenen Proxies und die aktuelle Response. Gespeicherte Presets und der ausgewählte API Key bleiben erhalten. Klicke zur Bestätigung auf Reset everything; alles andere bricht ab.

Senden und Abbrechen

Klicke auf Send, um den Request abzusenden. Die rechte Spalte wechselt in einen Ladezustand mit einem Spinner und einer Schaltfläche Cancel, während der Aufruf läuft. Klicke auf Cancel (oder tippe auf Mobilgeräten erneut auf die Schaltfläche), um abzubrechen. Ein abgebrochener Request stellt den Leerlauf-Platzhalter mit "Request canceled." wieder her, anstatt einen Fehler zu rendern.

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

Die Response lesen

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

Tab	Was es zeigt
Body	Geparster Body. Wechselt zwischen JSON-, HTML- und Text-Ansichten, je nachdem, was zurückkam.
Headers	Response-Header, einer pro Zeile.
Cookies	Vom Target zurückgegebene Cookies in geparsten (nach Host gruppiert) und rohen (Set-Cookie-Text) Ansichten. Die geparste Ansicht zeigt ein Badge `HO` bei host-only Cookies; Domain-Cookies sind unmarkiert.
Raw	Die vollständige JSON-Envelope, die von der API zurückgegeben wird.

Ein Meta-Streifen über den Tabs zeigt den Upstream-HTTP-Status, die Gesamtzeit, die Proxy-ID, die den Aufruf verarbeitet hat, und (für einen Scoped-Proxy-Aufruf) das aus zwei Buchstaben bestehende exit <CODE>. Für Auto-Durchläufe zeigt der Streifen auch an, welche Ladder-Stufe die Response geliefert hat, wie viele Teilversuche unternommen wurden und die ausgegebenen Credits.

Werte zwischen Durchläufen mitnehmen

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

Auto-Durchläufe bieten das vollständige session-Triple (proxy, cookies, userAgent).
Browser-Durchläufe bieten das Response-userAgent sowie die Proxy-ID, falls eine verwendet wurde.
Proxy-Durchläufe bieten die zurückgegebene Proxy-ID.

Klicke auf Carry und wähle, wo jeder Wert mit einem Klick angewendet werden soll: userAgent wird zu einem Header User-Agent bei Single oder Proxy, und die Proxy-ID wird in das Feld proxy bei Single oder Browser eingefügt. Felder, die einen mitgenommenen Wert erhalten, zeigen den roten "modified"-Punkt, damit du sehen kannst, was sich geändert hat.

Im Vollbildmodus erweitern

Das Erweiterungssymbol in der Response-Symbolleiste hebt die Response-Karte aus dem geteilten Layout heraus und in ein Vollbild-Overlay. Verwende es für tiefe JSON-Bäume, lange Set-Cookie-Dumps oder breite HTML-Bodys, wo die halbe Spaltenbreite eng wird. Die Seite selbst scrollt nicht mehr, während das Overlay geöffnet ist. Klicke erneut auf das Symbol (oder drücke Escape), um es zu minimieren.

Der cURL-Reproducer

Unter der Response zeigt ein curl-Block das exakte Kommandozeilen-Äquivalent für den Request, den du gerade erstellt hast. Kopiere es, um den Request in einem Terminal zu reproduzieren, ihn mit einem Teammitglied zu teilen oder in einen Bug Report einzufügen.

Für aufdeckbare Keys fügt ein Reveal key-Button neben dem Snippet den echten Klartext-Key direkt in den curl-Befehl ein, sodass du ihn direkt kopieren und ausführen kannst. Klicke erneut, um ihn zu verbergen. Legacy-Keys (erstellt bevor das Reveal-Feature veröffentlicht wurde) behalten einen PASTE_PLAINTEXT_FOR_<key-name> Platzhalter. Generiere den Key auf der API Keys-Seite neu, um ihn aufdeckbar zu machen.

Das Aufdecken wird jedes Mal in den Audit-Logs auf dem Server protokolliert. Der Klartext-Key bleibt nur für die aktuelle Seiten-Session im Speicher.

Presets speichern

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

Öffne Saved in der Toolbar, um deine Presets zu durchsuchen, umzubenennen oder zu löschen. Klicke auf ein beliebiges Preset, um es wieder in das Formular zu laden.

Preset-Feld	Was es speichert
Name	Ein kurzes Label (bis zu 100 Zeichen)
Description	Optionale Notizen (bis zu 500 Zeichen)
Endpoint	Für welche Engine das Preset ist (auto / single / proxy / browser)
Config	Die vollständige Request-Payload, einschließlich UI-Felder, Header, Cookies und Body

Presets sind auf dein Benutzerkonto beschränkt und werden nicht mit Teammitgliedern geteilt.

Replay aus der History

Jeder von dir ausgeführte Request wird protokolliert. Öffne History in der Toolbar, um deine letzten 20 Ausführungen zu sehen, die neuesten zuerst sortiert.

Jede Zeile zeigt Endpoint, Ziel-URL, Status und Zeit. Klicke bei einer beliebigen Zeile auf Replay, um den Request wieder ins Formular zu laden. Klicke dann auf Send, um ihn erneut auszuführen.

Die History ist automatisch auf dein Konto beschränkt: Du siehst nur deine eigenen Ausführungen.

Aus Activity öffnen

Der Detaildialog im Activity Log hat einen Open in Playground-Button. Klicke darauf und der Playground lädt sowohl den archivierten Request als auch die archivierte Response. Das Formular wird mit der gespeicherten Payload gefüllt. Die Response-Karte zeigt, was die API zu diesem Zeitpunkt zurückgegeben hat, mit einem "archived"-Badge auf dem Proxy-Meta-Streifen ("archived [, truncated] [, via ]").

Von dort aus kannst du einen Parameter ändern und auf Send klicken, um einen neuen Request gegen die Live-API auszuführen. Oder du untersuchst einfach die archivierte Payload, ohne sie neu auszuführen. Payloads werden für 24 Stunden aufbewahrt. Ältere Activity-Zeilen haben daher keine neu ladbare Response.

Tipps

Starte im Playground, bevor du Code für ein neues Ziel schreibst. Wenn Auto aktiviert ist, weißt du innerhalb von Sekunden, ob ein günstiger fetch ausreicht oder ob die Seite einen Browser-Solve erzwingt.
Bei länderspezifischen Zielen führst du einen Proxy-Aufruf mit gesetztem exitCountries aus und übergibst die zurückgegebene Proxy-ID an einen Browser-Aufruf, damit das JavaScript-Rendering über denselben Ausgang erfolgt.
Speichere ein Preset für jedes Ziel, das du regelmäßig scrapst. Das erneute Abspielen eines gespeicherten Presets erfordert einen Klick. Die Rekonstruktion des Requests aus dem Gedächtnis dauert länger.
Nutze den Cookies-Tab zum Debuggen von sessionbasiertem Scraping. Die rohe Set-Cookie-Ansicht zeigt genau, was das Ziel gesendet hat.
Wenn ein Ziel dich abweist, versuche einen anderen Eintrag in den Browser-Profilauswahlen, bevor du auf eine schwerere Engine zurückgreifst. Das Wechseln des präsentierten Browsers ist kostenlos, ein Browser-Render hingegen nicht.
Playground-Requests werden über den von dir gewählten Key abgerechnet. Verwende einen dedizierten Key mit geringer Quota für gelegentliche Tests, wenn du die Produktionsnutzung sauber halten möchtest.