← All posts
Product Update 5 min read

The Playground: Build and Test Requests in Your Dashboard

We shipped a Playground inside the Dashboard. Pick an endpoint, fill the fields, hit Send, copy the curl. Three endpoints, one cookie jar, every header.

playgrounddashboarddeveloper-experienceapi

The Playground is live in your Dashboard. Three endpoints, one cookie jar, every header parsed. Pick Single, Proxy, or Browser, fill in the request, hit Send. The response lands in the same screen with status, headers, body, and parsed cookies. When you're happy, copy the working curl into your code.

This isn't a separate page or a sandbox sitting behind a different URL. It runs against the live API with your real key. What you see in the Playground is what your production code will get back.

How It Works

You sign into the Dashboard, pick one of three endpoints, and the form rebuilds itself to show only the fields that endpoint actually accepts.

  • Single gets url, method, headers, unblocker, proxy, tryJsonData, followRedirects, and the timeout group.
  • Proxy gets the same set wrapped under a request block, plus the proxy-selection filters (country, city, ASN, anonymity, freshness).
  • Browser gets url, cookies, headers, and the wait conditions.

When you hit Send, the Dashboard authenticates the call against your account and POSTs to /api/{endpoint} on api.foura.ai. Your real API key never travels through the page. The Playground is the only place in the Dashboard where you can fire a billable request without exposing the key in the browser.

Here's the curl reproducer the Playground spits out for a basic Single request:

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
  }'

Paste that into a terminal or a build script and it behaves exactly like the Send button. We don't wrap the payload in a custom envelope or rename any of the fields. The Playground sends what the API takes, full stop.

What You See Back

The response panel shows the upstream status, total time, and (for Proxy calls) the proxy id that handled the request. Body, Headers, and Cookies each get their own tab.

Body. Auto-detected JSON renders in a collapsible viewer. HTML payloads switch to a preview pane so you can eyeball what the target site returned. Text drops to a plain monospace view. There's a search box on Body and Raw with prev/next jumping.

Headers. Parsed view with one row per name: value, or Raw for the full multi-hop response chain. Every redirect leaves its own header set behind, so chasing a 302 to its final destination is one click.

Cookies. The jar parses every Set-Cookie line from the response, tracks whether each cookie is host-only or domain-wide (RFC 6265 §5.3), and offers two views: per-host collapsible cards or the raw list. Toggle the jar on and the next request pulls matching cookies in automatically. For Single and Proxy that means a Cookie header on the outgoing request. For Browser it means a cookie array attached to the request object.

Presets save the whole request config under a name and description, so you can hop back to "test login on staging" without rebuilding it. History keeps your last twenty runs with status, content type, total time, and the proxy used.

Impact

The thing the Playground actually changes is the iteration loop.

Before, you wrote a tiny script (Node, Python, or shell), wired up your key, hit the API, printed the body, tweaked one header, ran it again. Maybe ten minutes from "I wonder what this site sends back" to having an answer.

In the Playground, that loop is closer to fifteen seconds. Click endpoint, paste URL, hit Send, look at the cookies, change unblocker from off to on, hit Send again. By the time you'd have opened your editor, you already know which version of the request works on your target.

We didn't ship the Playground to replace your real code. We shipped it so the path from "is this even doable on this site" to "yes, here's the curl that works" stops involving a side project.

For Power Users

A few things that aren't obvious from the front:

Presets carry the full payload. That includes the timeout group, validation rules, redirect limit, and any custom headers. When you save a preset, you're snapshotting a tested request, not just the URL. Useful when you keep a set of stable smoke tests across endpoints.

The cookie jar is per-session. It lives in your browser. We don't persist captured cookies server-side. Hard-reload the tab if you need a clean state.

The Raw tab and the form stay in sync. The form fields render the same JSON the Raw tab shows. Paste a payload into Raw and the form rehydrates. So a coworker can drop a working request in chat, you paste it into Raw, and the form fills itself in.

Browser cookies are object-shaped, not header-shaped. If you're sending cookies to the Browser endpoint by hand, each entry takes {name, value, domain?, path?, httpOnly?, secure?, sameSite?}. The Playground builds them correctly when the jar is on. If you're crafting them yourself, the schema match matters.

Outcomes show up in your activity feed. When the Playground fires a request, it counts the same as any other call against your key. You'll see it in your activity log with the right outcome label (success, client_error, application_error, rate_limit, service_error). Useful for repro on a flaky production call: rerun it in the Playground, find it in the activity log, share the link with the team.

What's Next

The Playground is the first step in a bigger push to make the Dashboard do more than show you what you already did. The patterns we see in the request log shape what ships next.

If you're using it today and something feels off, a field that doesn't match the docs, a cookie that didn't survive a redirect, a response that renders wrong, that's the feedback we read first. The Dashboard sees the requests. We see the trends.