Highlights
You can now compose, send, and replay requests against your own API key right in the dashboard. The new playground covers all three products and keeps cookies, presets, and history across runs. Two reliability fixes landed alongside it: unblocker: true was silently degrading for several weeks (it works again, end-to-end), and Browser now captures Cloudflare's passive-challenge cf_clearance cookie reliably.
What's New
The Dashboard Playground
/dashboard/#playground is a real workbench now. Three product tabs (Single, Proxy Finder, Browser), a URL bar, headers, body, all the per-product flags exposed and matched to each product's actual schema. Send the request, watch the response render with JSON, HTML, and text view modes. Search across response panes with Ctrl/Cmd+K. Expand the response into the full viewport when you need to read a wall of HTML.
A few things that came out of building it the way we'd want to use it ourselves:
- Cookies you receive get saved to a per-host jar. The next request to the same host attaches them automatically, and you can inspect, edit, or delete any cookie before sending.
- A working-proxies rail collects every proxy id that came back from a successful Proxy Finder run, so you can click "use" and reuse that proxy in a Single or Browser request without retyping.
- Save requests as presets. Replay any of your last 20 runs from a history dialog.
- A curl reproducer shows the exact command (with
x-api-key) you'd run from a terminal to send the same request.
The playground signs a short-lived internal token, so your plaintext key never leaves the dashboard. Quota, metrics, and last_used_at count against the key you picked, the same way they would if you'd sent the request from your own code.
unblocker: true works again, end-to-end
We caught a build issue that had been silently downgrading Single and Proxy Finder requests with unblocker: true for the past several weeks. The build shipped without the bypass actually wired in, so requests that should have cleared handshake-level anti-bot walls were getting a generic request signature instead. Sites that should have let us through were blocking us.
Fix is deployed. We verified end-to-end across eleven real-world targets, including three on Cloudflare interstitials that previously needed Browser to clear. Single passes them on its own. The chained Proxy Finder + Browser + Single flow (find a proxy, get a cf_clearance cookie from Browser, send the page request with Single plus the cookie plus the same proxy) returns full HTML in one round trip.
This one is on us. unblocker: true worked the day it shipped, and broke quietly during a routine rebuild. If you ran a request with unblocker: true against a protected site in the last few weeks and saw a 403 where you expected a 200, that's why. Try it again.
Browser handles Cloudflare's passive JavaScript challenge
Cloudflare has two challenge modes. The active mode (HTTP 403 plus interstitial) we already handled. The passive one is sneakier: the page returns 200 immediately, but Cloudflare injects an async JavaScript probe that fingerprints the client and only then issues the cf_clearance cookie. Before this fix, Browser finalized the response before the probe could complete, so the clearance cookie never landed in the jar.
Browser now listens for the Set-Cookie event explicitly and waits for cf_clearance if it sees the passive-challenge marker in the body. No polling, no fixed grace period, no extra wait for non-Cloudflare sites. Twelve real-world domains in the test suite, three of them on the passive path, return clearance cookies reliably now.
Closed an SSRF gap at the API edge
A valid pk_live_... API key isn't a license to reach our private network. The API now rejects any target whose hostname literal or DNS resolution lands in an RFC 5735, 6598, or IPv6 reserved block. The same check runs at every backend product as a second line of defense.
You won't see anything different on the surface. We close a class of internal-network probe before it can complete a TCP handshake.
Blog gets unique social previews, pagination fixed
Every blog post now generates its own Open Graph image with the post title and excerpt rendered onto a brand card. Paste a foura.ai/blog/... link into Discord, LinkedIn, Slack, or Twitter and you'll see the post-specific preview instead of a generic fallback.
Pagination on the blog index was quietly broken. The "Older" button dropped you back on page 1. We rebuilt it on path-based URLs (/blog/page/N/), added numbered navigation with a smart window, and added proper rel=prev/next link tags for paginated series. Old ?page=N URLs 301 to the new form, so nothing crawled before this is lost.
Under the Hood
Our MCP server is live at mcp.foura.ai for any LLM tooling that speaks Model Context Protocol. Authentication is the same pk_live_... Bearer token you use against the REST API. It exposes the three products as tools (Single, Proxy Finder, Browser) and a handful of prompts. If you're wiring FourA into Claude Code or any MCP-capable agent, you can stop running a local bridge.
If you've been holding off on the dashboard because the prior playground was a hint of a thing, open it this week. It's the surface we now use ourselves when something looks wrong against an API target.