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 Auto, Single, Proxy, and Browser side by side.
Open it at foura.ai/dashboard#playground.
What It Does
One form. Four engines. Real traffic.
- Auto: smart fetch. You pass a URL plus a
validaterule and FourA picks the cheapest path that works. - Single: direct HTTP fetch with realistic browser-like wire characteristics
- Proxy: managed rotating proxy fetch, optionally scoped to target-visible countries
- 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 lists every active key you can use: your own under My Keys, then one group per organization you belong to. Any member can run an organization's key, and a request on it counts against the organization owner's plan. 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 Mode
A top Mode row toggles between Auto and the manual engines. When Auto is selected, the form switches to the minimal Auto surface (URL plus validate plus a few knobs). Both rows are always shown: Mode: Auto, and Product: Single, Proxy, Browser. Picking one deselects the other. Switching products swaps which fields are visible and which engine the request hits. The current selection is preserved when you reload the page.
| Mode | When to use it |
|---|---|
| Auto | New target or mixed-protection site. Auto picks the cheapest path and remembers what works. |
| Single | Fast HTTP fetch. Best first pick for a known host. |
| Proxy | Same fetch with automatic proxy rotation. Set exitCountries when you need a target-visible country. |
| 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, and Auto 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, as a read-only preview with Copy JSON, and the curl reproducer under it |
Whatever you change in UI / Body / Headers / Cookies is reflected in Raw. You can't type into Raw: change the request on the other tabs. A red dot appears on any tab or collapsible section that holds a value different from the engine's defaults, so you can spot at a glance what you've customized.
UI Pane Sections
The UI tab groups settings into collapsible sections. Empty fields fall back to the engine's schema default. Sections that don't apply to the current Mode are hidden.
- Timeouts:
timeout_ms,connect_timeout_ms,accept_timeout_ms,server_response_timeout_ms,dns_cache_timeout_sec. Auto exposes onlytimeout_ms(the total budget). - Redirects: toggle and set
followRedirects(0-20). Single and Proxy. Browser follows redirects on its own. - Flags:
unblockerfor Single, Proxy, and Browser (unblockeron Browser completes the checks a page asks for);tryJsonDataandreturnBufferfor Single and Proxy. Auto exposesforceProxyandreturnSessioninstead. - Proxy: pick a specific proxy ID for Single or Browser, or set
maxTries, the Proxy outer timeout,exitCountries,exitClass, andignoreProxiesfor the Proxy engine. Auto also exposesignoreProxiesandexitClass. TheexitClassselect has three states: unset sends no field at all,standardsays the request must never escalate, andpremiumlets it escalate to a premium exit when the standard pool is struggling. Unset andstandardare different requests, so leave the select empty unless you mean one of the two. Premium needs a plan that includes premium exits: see exitClass. - Browser profile: three cascading dropdowns, os, browser, and version, listing what FourA can actually present. They show up in Single and Proxy mode. Leave them empty for the newest Chrome. Each select narrows the other two, so a combination that resolves to nothing never appears. The section needs
unblockeron: with it off no browser headers are sent, a profile would only half-apply, and the API refuses the request instead. - Browser: browser-only options such as
checkStatusandcheckText. - Validate: status accept and status fail take comma-separated status codes (
validate.status), and body accept and body fail take substrings with|-separated alternatives (validate.data). Available for Single, Proxy, and Auto. Browser usescheckStatusandcheckTextinstead. The form has no field for header rules (validate.headers).
Once a run returns a proxy that worked, a Working proxies section appears at the end of the UI tab. It lists up to 20 proxy IDs, newest first, each with its exit country and time. use puts one into the proxy field on Single or Browser (the Proxy engine finds its own), and × drops it from the list.
Exit Country Scoping (Proxy Mode)
The exitCountries field on Proxy accepts a comma-separated list of two-letter target-visible country codes (CZ, GB). Values are trimmed, uppercased, and deduplicated on submit. Selection is a strict allowlist: proxies with unknown exits are excluded and the request never falls back to another country. If the current pool has no match, the response returns code: "no_eligible_proxy" with the requested scope echoed back in details.exitCountries. Preserve the scope and retry later.
When a proxy call succeeds under scoping, the response strip shows exit <CODE> next to the proxy ID so you can verify the served country matches what you asked for.
Toolbar Reset
The Reset button on the toolbar (next to History and Saved) clears the playground back to a clean slate. Because it's destructive, it opens a confirm dialog that lists exactly what will be wiped: all three product forms (Single, Proxy, Browser), any saved cookies in the jar, any carried proxies, and the current response. Saved presets and the selected API key are kept. Click Reset everything to confirm; anything else cancels.
Sending and Canceling
Click Send to fire the request. The right column flips to a loading state with a spinner and a Cancel button while the call is in flight. Click Cancel (or hit the button again on mobile) to abort. A canceled request restores the idle placeholder with "Request canceled." instead of rendering an error.
The response card switches to the result the moment the request completes (or fails). On a phone, or in any window narrow enough to put the response under the form, the page brings the response card into view when it arrives low on the screen. Auto runs can take longer than the manual engines because the ladder may climb several rungs on a cold target.
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. The parsed view shows an HO badge on host-only cookies; domain cookies are unmarked. |
| Raw | The full JSON envelope returned by the API. |
The response toolbar has Copy and Download for the whole response, and Find in response (Ctrl+K or Cmd+K) to search the open tab, with Enter and Shift+Enter to step through the matches. Body, Headers, and Cookies also have their own Copy and Download for just that tab.
A meta strip above the tabs shows the upstream HTTP status, the total time, the proxy ID that handled the call, and (for a scoped Proxy call) the two-letter exit <CODE>. For Auto runs, the strip also shows which ladder rung delivered the response, how many sub-attempts were made, and the credits spent.
What the Call Needed
A sentence under the meta strip says what carried the page, in words. For an Auto run it names the rung (a session FourA already had for the host, a plain request, a rotating proxy, a real browser, or a browser first and then a cheap replay), whether a challenge was solved, how many attempts it took, and what it cost.
When one of your plan's limits refused the call, the sentence says so first: "Stopped by your plan, not by the site", followed by which limit (today's browser requests used up, too many requests in flight, this period's credits spent, and so on) and a link to Usage & Limits. The line is built from the X-FourA-Limit code the API returned, so a hard page that fails tells you whether the site stopped it or the plan did.
Carry Values Between Runs
After any run that returned reusable session data, a small Carry control on the response toolbar shows what's available:
- Auto runs offer the full
sessiontriple (proxy,cookies,userAgent). - Browser runs offer the response
userAgent, plus the proxy ID if one was used. - Proxy runs offer the returned proxy ID, the browser profile when the rotation picked one you didn't ask for, and the
exitClassthat served the call, so a premium answer can be sent straight back.
Click Carry and pick where to apply each value in one click: userAgent becomes a User-Agent header on Single or Proxy, and the proxy ID drops into the proxy field on Single or Browser. Fields that receive a carried value show the "modified" red dot so you can see what changed.
A carried browser profile fills the three os, browser, and version selects and turns unblocker on, the same rule that applies when you pick a profile by hand. It's offered only once the profile catalogue has loaded, since the form is three selects and not an id field.
The profile is the one value that says the request which worked was not the request you typed: Proxy reports profile only when it moved to a browser family you didn't ask for. Replay without it and you replay the version that failed. See Why a Proxy Request Ran Out of Tries.
Expand to Full Screen
The expand icon on the response toolbar lifts the response card out of the split layout and into a full-screen overlay. Use it for deep JSON trees, long Set-Cookie dumps, or wide HTML bodies where the half-width column gets cramped. The page itself stops scrolling while the overlay is open. Click the icon again (or press Escape) to collapse.
The curl Reproducer
On the request's Raw tab, under the JSON, a curl block shows the exact command line equivalent of the request you're building, with a Copy curl button. Copy it to repro the request from a terminal, share it with a teammate, or paste it into a bug report.
For revealable keys, a Reveal key button next to the snippet drops the real plain-text key straight into the curl so you can copy-and-run as is. Click again to hide. Legacy keys (created before the reveal feature shipped) keep a PASTE_PLAINTEXT_FOR_<key-name> placeholder; regenerate the key from the API Keys page to make it revealable.
The reveal is audit-logged on the server every time, and the plain key only lives in memory for the current page session.
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 see your presets. Click Load to fill the form, or Delete to remove one.
A request opened from the FourA Chrome extension's DevTools tab loads with the extension's key selected when that key is in your account, and the page says so. Otherwise it asks you to pick a key. A replayed request that doesn't set unblocker runs with it on, as the API does.
| Preset field | What it stores |
|---|---|
| Name | A short label (up to 100 characters) |
| Description | Optional notes (up to 500 characters) |
| Endpoint | Which engine the preset is for (auto / 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.
Opening from Activity
The Activity Log detail dialog has an Open in Playground button. Click it and the Playground loads with both the archived request and the archived response. The form fills in from the stored payload, and the response card shows what the API returned at that moment with an "archived" badge on the proxy meta strip ("archived
From there you can change a parameter and hit Send to run a new request against the live API, or just inspect the archived payload without re-running it. Payloads are kept for 24 hours, so older Activity rows won't have a reloadable response.
Tips
- Start in Playground before writing code against a new target. With Auto on, you'll know within seconds whether a cheap fetch is enough or whether the site forces a browser solve.
- For country-locked targets, run one Proxy call with
exitCountriesset, then carry the returned proxy ID into a Browser call so the JavaScript render happens through the same exit. - 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.
- When a target refuses you, try another entry in the Browser profile selects before reaching for a heavier engine. Swapping the presented browser is free; a browser render isn't.
- 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.
Related
- API Endpoints: Full parameter reference for all four engines, including
exitCountriesand the browser profile fields - Smart Fetch (Auto): What Auto does under the hood
- Choosing the Right Endpoint: When to pick Auto vs Single vs Proxy vs Browser
- API Keys: Manage the keys you authenticate Playground requests with
- Activity Log: Open a past request straight into Playground
- Dashboard Overview: All sidebar sections