← Alle Beiträge
Produktupdate 5 Min. Lesezeit

Der Playground: Requests im Dashboard erstellen und testen

Wir haben einen Playground direkt im Dashboard veröffentlicht. Wähle einen Endpoint, fülle die Felder aus, klicke auf Senden und kopiere den curl. Drei Endpoints, ein Cookie-Jar, jeder Header.

playgrounddashboarddeveloper-experienceapi

Der Playground ist live in deinem Dashboard. Drei Endpoints, ein Cookie-Jar, jeder Header geparst. Wähle Single, Proxy oder Browser, fülle den Request aus und klicke auf Senden. Die Response landet auf demselben Bildschirm mit Status, Headers, Body und geparsten Cookies. Wenn du zufrieden bist, kopiere den funktionierenden curl in deinen Code.

Dies ist keine separate Seite oder eine Sandbox, die hinter einer anderen URL liegt. Er läuft direkt gegen die Live-API mit deinem echten Key. Was du im Playground siehst, ist genau das, was dein Produktionscode zurückerhält.

Wie es funktioniert

Du meldest dich im Dashboard an, wählst einen von drei Endpoints und das Formular baut sich selbst neu auf, um nur die Felder anzuzeigen, die dieser Endpoint tatsächlich akzeptiert.

  • Single erhält url, method, headers, unblocker, proxy, tryJsonData, followRedirects und die Timeout-Gruppe.
  • Proxy erhält das gleiche Set, verpackt in einem request-Block, plus die Proxy-Auswahlfilter (Land, Stadt, ASN, Anonymität, Aktualität).
  • Browser erhält url, cookies, headers und die Wartebedingungen.

Wenn du auf Senden klickst, authentifiziert das Dashboard den Aufruf für dein Konto und sendet einen POST-Request an /api/{endpoint} auf api.foura.ai. Dein echter API-Key wird dabei nie über die Seite übertragen. Der Playground ist der einzige Ort im Dashboard, an dem du einen kostenpflichtigen Request ausführen kannst, ohne den Key im Browser offenzulegen.

Hier ist der curl-Befehl zur Reproduktion, den der Playground für einen einfachen Single-Request ausgibt:

curl -X POST 'https://api.foura.ai/api/single' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: YOUR_API_KEY' \
  --data-raw '{
    "url": "https://example.com/products",
    "method": "GET",
    "unblocker": true,
    "tryJsonData": true
  }'

Füge das in ein Terminal oder ein Build-Skript ein und es verhält sich exakt wie der Senden-Button. Wir verpacken die Payload nicht in einen eigenen Wrapper oder benennen Felder um. Der Playground sendet das, was die API akzeptiert, Punkt.

Was du zurückbekommst

Das Response-Panel zeigt den Upstream-Status, die Gesamtzeit und (bei Proxy-Aufrufen) die Proxy-ID, die den Request verarbeitet hat. Body, Headers und Cookies erhalten jeweils einen eigenen Tab.

Body. Automatisch erkanntes JSON wird in einer einklappbaren Ansicht gerendert. HTML-Payloads wechseln in ein Vorschaufenster, damit du direkt sehen kannst, was die Zielseite zurückgegeben hat. Text wechselt in eine einfache Monospace-Ansicht. Es gibt ein Suchfeld für Body und Raw mit Vor-/Zurück-Navigation.

Headers. Eine geparste Ansicht mit einer Zeile pro name: value oder Raw für die vollständige Multi-Hop-Response-Kette. Jeder Redirect hinterlässt seinen eigenen Header-Satz, sodass das Verfolgen eines 302-Status bis zum endgültigen Ziel nur einen Klick erfordert.

Cookies. Der Cookie-Jar parst jede Set-Cookie-Zeile aus der Response, verfolgt, ob jeder Cookie Host-only oder Domain-wide ist (RFC 6265 §5.3), und bietet zwei Ansichten: einklappbare Karten pro Host oder die Raw-Liste. Schalte den Cookie-Jar ein und der nächste Request zieht passende Cookies automatisch mit. Für Single und Proxy bedeutet das einen Cookie-Header im ausgehenden Request. Für Browser bedeutet es ein Cookie-Array, das an das Request-Objekt angehängt ist.

Presets speichern die gesamte Request-Konfiguration unter einem Namen und einer Beschreibung, sodass du schnell zu "Test-Login auf Staging" zurückkehren kannst, ohne alles neu aufzubauen. Die History speichert deine letzten zwanzig Durchläufe mit Status, Content-Type, Gesamtzeit und dem verwendeten Proxy.

Auswirkungen

Das, was der Playground tatsächlich verändert, ist der Iterationszyklus.

Vorher hast du ein winziges Skript geschrieben (Node, Python oder Shell), deinen Key eingebunden, die API aufgerufen, den Body ausgegeben, einen Header angepasst und es erneut ausgeführt. Vielleicht zehn Minuten von "Ich frage mich, was diese Seite zurückgibt" bis zu einer Antwort.

Im Playground liegt dieser Zyklus eher bei fünfzehn Sekunden. Klicke auf den Endpoint, füge die URL ein, klicke auf Senden, sieh dir die Cookies an, schalte unblocker von off auf on, klicke erneut auf Senden. Bis du deinen Editor geöffnet hättest, weißt du bereits, welche Version des Requests auf deinem Ziel funktioniert.

Wir haben den Playground nicht veröffentlicht, um deinen echten Code zu ersetzen. Wir haben ihn veröffentlicht, damit der Weg von "Ist das auf dieser Seite überhaupt machbar?" zu "Ja, hier ist der funktionierende curl-Befehl" kein eigenes Nebenprojekt mehr erfordert.

Für Power-User

Ein paar Dinge, die auf den ersten Blick nicht offensichtlich sind:

Presets enthalten die vollständige Payload. Das schließt die Timeout-Gruppe, Validierungsregeln, das Redirect-Limit und alle benutzerdefinierten Headers ein. Wenn du ein Preset speicherst, erstellst du einen Snapshot eines getesteten Requests, nicht nur der URL. Nützlich, wenn du eine Reihe stabiler Smoke-Tests über verschiedene Endpoints hinweg verwaltest.

Der Cookie-Jar gilt pro Session. Er lebt in deinem Browser. Wir speichern erfasste Cookies nicht serverseitig. Lade den Tab neu (Hard-Reload), wenn du einen sauberen Zustand benötigst.

Der Raw-Tab und das Formular bleiben synchron. Die Formularfelder rendern dasselbe JSON, das der Raw-Tab anzeigt. Füge eine Payload in Raw ein und das Formular rehydriert. So kann ein Kollege einen funktionierenden Request im Chat teilen, du fügst ihn in Raw ein und das Formular füllt sich von selbst aus.

Browser-Cookies sind als Objekte strukturiert, nicht als Header. Wenn du Cookies manuell an den Browser-Endpoint sendest, erwartet jeder Eintrag {name, value, domain?, path?, httpOnly?, secure?, sameSite?}. Der Playground baut sie korrekt auf, wenn der Cookie-Jar aktiv ist. Wenn du sie selbst erstellst, muss das Schema exakt übereinstimmen.

Ergebnisse werden in deinem Aktivitäts-Feed angezeigt. Wenn der Playground einen Request ausführt, zählt dies wie jeder andere Aufruf gegen deinen Key. Du siehst ihn in deinem Aktivitäts-Log mit dem richtigen Ergebnis-Label (success, client_error, application_error, rate_limit, service_error). Nützlich für die Reproduktion eines instabilen Produktionsaufrufs: Führe ihn im Playground erneut aus, finde ihn im Aktivitäts-Log und teile den Link mit dem Team.

Was als Nächstes kommt

Der Playground ist der erste Schritt einer größeren Initiative, um das Dashboard zu mehr als nur einer Anzeige deiner vergangenen Aktionen zu machen. Die Muster, die wir im Request-Log sehen, bestimmen, was als Nächstes veröffentlicht wird.

Wenn du ihn heute nutzt und sich etwas nicht richtig anfühlt (ein Feld, das nicht mit der Dokumentation übereinstimmt, ein Cookie, der einen Redirect nicht überstanden hat, eine Response, die falsch gerendert wird), ist das genau das Feedback, das wir zuerst lesen. Das Dashboard sieht die Requests. Wir sehen die Trends.