Playground

Der Playground (Seitenleiste > Playground) ermöglicht es dir, Live-API-Requests mit deinem echten Key auszuführen, ohne Code zu schreiben. Es ist der schnellste Weg, eine neue Zielseite zu testen, eine fehlerhafte Response zu debuggen oder Single, Proxy und Browser direkt miteinander zu vergleichen.

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

Funktionen

Ein Formular. Drei Engines. Echter Traffic.

Single: direkter HTTP-Abruf mit realistischen, browserähnlichen Übertragungseigenschaften
Proxy: verwalteter, rotierender Proxy-Abruf
Browser: öffnet die URL in einer Chrome-Browserinstanz für JS-gerenderte Seiten

Requests werden mit dem API-Key ausgeführt, den du oben auf der Seite auswählst. Die Nutzung wird auf das Kontingent dieses Keys angerechnet, genau wie bei einem produktiven Aufruf, verbrauche dein Kontingent also nicht beim Testen.

Key auswählen

Das API-Key-Dropdown zeigt jeden aktiven Key in deinem Bereich: persönliche Keys, von dir verwaltete Organisations-Keys und für das Team freigegebene Keys, auf die du Zugriff hast. Wähle den Key aus, über den der Request abgerechnet werden soll. Wenn du noch keine aktiven Keys hast, leitet dich ein Hinweis direkt zur Seite API Keys weiter, um einen zu erstellen.

Produkt auswählen

Drei Pills befinden sich über dem Formular: Single, Proxy, Browser. Das Wechseln der Pills ändert die sichtbaren Felder und die Engine, die der Request anspricht. Die aktuelle Auswahl bleibt beim Neuladen der Seite erhalten.

Produkt	Anwendungsfall
Single	Schneller HTTP-Abruf. Die beste erste Wahl für jede URL.
Proxy	Gleicher Abruf mit automatischer Proxy-Rotation. Nutze dies, wenn Single blockiert wird.
Browser	Lädt die Seite in einer Chrome-Browserinstanz. Nutze dies, wenn Daten erst nach der Ausführung von JavaScript erscheinen.

Request erstellen

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 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 in fünf Tabs alles Weitere konfigurieren:

Tab	Funktion
UI	Formularfelder für Timeouts, Redirects, Flags, Proxy, browserspezifische Optionen und Validierungsregeln
Body	Freitext-Body für POST- / PUT- / PATCH-Requests
Headers	Benutzerdefinierte Request-Header als Key-Value-Paare
Cookies	Cookies, die mit dem Request gesendet werden sollen
Raw	Das exakte JSON-Payload, das gesendet wird, direkt editierbar

Alle Änderungen in UI / Body / Headers / Cookies werden direkt in Raw gespiegelt. Das Bearbeiten von Raw funktioniert ebenfalls, wobei die anderen Tabs entsprechend aktualisiert werden.

Bereiche des UI-Panels

Der UI-Tab gruppiert Einstellungen in ausklappbare Bereiche. Leere Felder fallen auf den Schema-Standardwert der Engine zurück.

Timeouts: timeout_ms, connect_timeout_ms, accept_timeout_ms, server_response_timeout_ms, dns_cache_timeout_sec
Redirects: Aktivieren und Festlegen von followRedirects (0-20). Nur Single + Proxy. Browser folgt Redirects selbstständig.
Flags: unblocker, tryJsonData, returnBuffer. Single + Proxy.
Proxy: Wähle eine bestimmte Proxy-ID für Single oder Browser, oder lege maxTries, das äußere Proxy-Timeout und ignoreProxies für die Proxy-Engine fest.
Browser: Nur-Browser-Optionen wie checkStatus and checkText.
Validate: validate.status (Statuscodes), validate.headers (Header-Key-Value-Regeln) und validate.data (Substrings für Body-Erfolg/-Fehler, durch | getrennte Alternativen) Erfolgs-/Fehlerregeln.

Felder, die für das aktuell ausgewählte Produkt nicht gelten, werden ausgeblendet.

Der Reset-Button in der Toolbar (neben History) setzt das Formular des aktiven Produkts auf die Standardwerte zurück. Die Standardwerte lassen unblocker und tryJsonData aktiviert, was dem häufigsten Ausgangspunkt entspricht. Nutze ihn, wenn du dich weit von einer funktionierenden Basis entfernt hast und neu anfangen willst, ohne die Seite neu zu laden.

Senden und Abbrechen

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

Die Response-Karte wechselt zum Ergebnis, sobald der Request abgeschlossen ist (oder fehlschlägt).

Response lesen

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

Tab	Inhalt
Body	Geparster Body. Wechselt je nach Rückgabe zwischen JSON-, HTML- und Textansicht.
Headers	Response-Header, einer pro Zeile.
Cookies	Vom Ziel zurückgegebene Cookies, sowohl in der geparsten (nach Host gruppierten) als auch in der Raw-Ansicht (Set-Cookie-Text). Die geparste Ansicht zeigt ein `HO`-Badge bei Host-only-Cookies; Domain-Cookies sind unmarkiert.
Raw	Das vollständige von der API zurückgegebene JSON-Envelope.

Eine Meta-Leiste über den Tabs zeigt den Upstream-HTTP-Status, die Gesamtzeit und (bei Proxy- oder Single-mit-Proxy-ID-Requests) die Proxy-ID, die den Aufruf verarbeitet hat. Buttons zum Kopieren und Herunterladen befinden sich oben rechts in jedem Bereich, sodass du den Body oder die Header mit einem Klick in eine Datei exportieren kannst.

Vollbild-Ansicht

Das Vergrößern-Icon in der Response-Toolbar 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-Bodys, bei denen die Spalte mit halber Breite zu eng wird. Das Scrollen der Seite selbst wird blockiert, solange das Overlay geöffnet ist. Klicke erneut auf das Icon (oder drücke Escape), um es zu schließen.

Der curl-Reproducer

Unter der Response zeigt ein curl-Block die exakte Befehlszeilen-Entsprechung des soeben erstellten Requests. Kopiere ihn, um den Request im Terminal zu reproduzieren, ihn mit Teammitgliedern zu teilen oder in einen Bug-Report einzufügen.

Bei anzeigbaren 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 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 anzeigbar zu machen.

Das Offenlegen wird jedes Mal auf dem Server protokolliert, und der Klartext-Key verbleibt nur für die aktuelle Sitzung im Arbeitsspeicher.

Presets speichern

Wenn du dieselbe Zielseite immer wieder konfigurierst, speichere sie ab. 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 zu durchsuchen, umzubenennen oder zu löschen. Klicke auf ein Preset, um es wieder in das Formular zu laden.

Preset-Feld	Gespeicherter Inhalt
Name	Ein kurzes Label (bis zu 100 Zeichen)
Description	Optionale Notizen (bis zu 500 Zeichen)
Endpoint	Für welches Produkt das Preset bestimmt ist (single / proxy / browser)
Config	Das vollständige Request-Payload, einschließlich UI-Feldern, Headern, Cookies und Body

Presets sind an dein Benutzerkonto gebunden und werden nicht mit Teammitgliedern geteilt.

Aus der History wiederholen

Jeder ausgeführte Request wird protokolliert. Öffne History in der Toolbar, um deine letzten 20 Durchläufe zu sehen, sortiert nach den neuesten.

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

Die History ist automatisch an dein Konto gebunden: Du siehst nur deine eigenen Durchläufe.

Aus Activity öffnen

Der Detaildialog im Activity Log enthält 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 dem gespeicherten Payload befüllt, und die Response-Karte zeigt an, was die API zu diesem Zeitpunkt zurückgegeben hat, versehen mit einem "archived"-Badge auf 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 das archivierte Payload prüfen, ohne es erneut auszuführen. Payloads werden 24 Stunden lang aufbewahrt, sodass ältere Activity-Zeilen keine neu ladbare Response haben.

Tipps

Starte im Playground, bevor du Code für ein neues Ziel schreibst. Du weißt innerhalb von Sekunden, ob Single ausreicht oder ob du Browser benötigst.
Speichere ein Preset für jedes Ziel, das du regelmäßig scrapest. Das Wiederholen eines gespeicherten Presets erfordert nur einen Klick; den Request aus dem Gedächtnis zu rekonstruieren, dauert länger.
Nutze den Cookies-Tab, um sessionbasiertes Scraping zu debuggen. Die rohe Set-Cookie-Ansicht zeigt genau, was das Ziel gesendet hat.
Playground-Requests werden über den von dir ausgewählten Key abgerechnet. Nutze einen dedizierten Key mit geringem Kontingent für gelegentliches Testen, um die produktive Nutzung sauber zu halten.