Docs › Dashboard › Playground

Playground

The Playground (sidebar > Playground) lets you run live API requests against your real key without writing any code. It's the fastest way to try a new target site, debug a tricky response, or compare Single, Proxy, and Browser side by side.

Open it at foura.ai/dashboard#playground.

What It Does

One form. Three engines. Real traffic.

  • Single: direct HTTP fetch with realistic browser-like wire characteristics
  • Proxy: managed rotating proxy fetch
  • Browser: opens the URL in a Chrome browser instance for JS-rendered sites

Requests run against the API key you pick at the top of the page. Usage counts against that key's quota the same way a production call would, so don't burn through your plan in testing.

Picking a Key

The API key dropdown shows every active key within your scope: personal keys, org keys you administer, and team-shared keys you can access. Pick the one you want the request to bill against. If you don't have any active keys yet, an inline prompt links you to the API Keys page to create one.

Choosing a Product

Three pills sit above the form: Single, Proxy, Browser. Switching pills swaps which fields are visible and which engine the request hits. The current selection is preserved when you reload the page.

Product When to use it
Single Fast HTTP fetch. Best first pick for any URL.
Proxy Same fetch with automatic proxy rotation. Use when Single keeps getting blocked.
Browser Loads the page in a Chrome browser instance. Use when the data appears only after JavaScript runs.

Building the Request

URL Row

The top row holds the HTTP method (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), the target URL, and the Send button. Single + Proxy honor every method. Browser ignores the method (Chrome always issues GET for navigation) and the body.

Request Tabs

Below the URL row, five tabs let you fill in everything else:

Tab What it controls
UI Form fields for timeouts, redirects, flags, proxy, browser-specific options, and validate rules
Body Free-form body for POST / PUT / PATCH requests
Headers Custom request headers as key-value pairs
Cookies Cookies to send with the request
Raw The exact JSON payload that will be sent, editable directly

Whatever you change in UI / Body / Headers / Cookies is reflected in Raw. Editing Raw works too, with the other tabs updating to match.

UI Pane Sections

The UI tab groups settings into collapsible sections. Empty fields fall back to the engine's schema default.

  • Timeouts: timeout_ms, connect_timeout_ms, accept_timeout_ms, server_response_timeout_ms, dns_cache_timeout_sec
  • Redirects: toggle and set followRedirects (0-20). Single + Proxy only. Browser follows redirects on its own.
  • Flags: unblocker, tryJsonData, returnBuffer. Single + Proxy.
  • Proxy: pick a specific proxy ID for Single or Browser, or set maxTries, the Proxy outer timeout, and ignoreProxies for the Proxy engine.
  • Browser: browser-only options such as checkStatus and checkText.
  • Validate: validate.status, validate.headers, validate.data accept / fail rules.

Fields that don't apply to the currently selected product are hidden.

Sending the Request

Click Send. The Send button shows a spinner while the request is in flight. The response renders in the right column when the call finishes (or fails). You can interrupt a long-running browser request by clicking Send again, which cancels and restarts.

Reading the Response

The response column mirrors the request layout with its own tabs:

Tab What it shows
Body Parsed body. Switches between JSON, HTML, and Text views depending on what came back.
Headers Response headers, one per line.
Cookies Cookies returned by the target, in both parsed (host-grouped) and raw (Set-Cookie text) views.
Raw The full JSON envelope returned by the API.

A meta strip above the tabs shows the upstream HTTP status, the total time, and (for Proxy / single-with-proxy-id requests) the proxy ID that handled the call. Copy and download buttons sit on the top right of each pane, so you can pull the body or headers into a file with one click.

Saving Presets

If you find yourself reconfiguring the same target repeatedly, save it. Click Save on the request tabs row to store the current configuration as a named preset.

Open Saved in the toolbar to browse, rename, or delete your presets. Click any preset to load it back into the form.

Preset field What it stores
Name A short label (up to 100 characters)
Description Optional notes (up to 500 characters)
Endpoint Which product the preset is for (single / proxy / browser)
Config The full request payload, including UI fields, headers, cookies, and body

Presets are scoped to your user account and aren't shared with team members.

Replaying from History

Every request you run is logged. Open History in the toolbar to see your last 20 runs, sorted newest first.

Each row shows the endpoint, target URL, status, and time. Click Replay on any row to load that request back into the form, then Send to run it again.

History is automatically scoped to your account: you only see your own runs.

Tips

  • Start in Playground before writing code against a new target. You'll know within seconds whether Single is enough or whether you need Browser.
  • Save a preset for every target you scrape regularly. Replaying a saved preset takes one click; reconstructing the request from memory takes longer.
  • Use the Cookies tab to debug session-based scraping. The raw Set-Cookie view shows exactly what the target sent.
  • Playground requests are billed against the key you pick. Use a dedicated low-quota key for casual exploration if you want to keep production usage clean.
Last updated: May 20, 2026
← Account Settings