Changelog

The Dashboard playground now has an Auto tab. Paste a URL, hit Send, watch Auto crack it. You can set your own success criteria via the Validate group, and a URL history typeahead suggests previously-used URLs as you type (one shared list across all endpoints, capped at the last 50). Non-applicable fields hide per engine, so each tab shows only the inputs it actually uses.

A cold Auto solve can take several minutes, and the request now stays open for its whole budget. Errors from any layer come back as JSON your client can parse.

Every Auto response now carries a meta object (which rung won, whether a challenge was solved, attempt count, total credits) plus the working session (proxy, cookies, userAgent) so you can see what cracked the target and replay it yourself. The session.proxy field is the opaque base36 proxy ID, never a raw address. Set returnSession: false if you don't want the session in the response.

Cookie-reusable sites (bet365 was the canary) were sticking on the expensive browser solve at 15 credits per request instead of dropping to the cheap 2-credit replay after the first solve. Two bugs: the latch fired on any transient transport error, and a successful browser replay never refreshed the session cookies. Fixed both. Repeat requests on a cookie-reusable site now cost 2 credits after the first solve, exactly as the pricing implies.

Auto now handles non-interactive Cloudflare challenges (the "Checking your browser" wall some protected sites serve) end-to-end, instead of returning the challenge page as if it were content. Two related cases also got fixed: a transport 200 hiding a challenge interstitial now escalates to a real solve, and a challenge that re-serves the wall after dropping a clearance cookie now reloads and pulls the real content. Marathonbet is the headline site that newly passes; vinted and a few other interstitial-on-200 targets also benefit.

Refreshing the Playground no longer flashes the static state before yours reappears. A new Reset button (behind a confirm) clears all three request tabs, cookies, and carried proxies in one go. A response can now also carry its proxy ID or User-Agent into the next request when you ask for it, instead of auto-applying behind your back.

Every API response now carries an x-foura-credits header showing what that call cost. A new Budget view in the Dashboard breaks credit spend down by API key, domain, and client IP with a timeline chart, and the Playground shows the same on each response so you can size a workload before scaling it up.

Every post on the blog now renders in English, Bulgarian, German, Polish, Vietnamese, Chinese, and Arabic. Code blocks, markdown, and links are preserved, and search returns localized titles.

Each Single response now includes the proxy ID that handled the request, and Browser responses do the same. Useful for chained calls that need to stick to the same proxy.

The main site now renders in Arabic with full right-to-left layout, bringing the locale list to seven. If your browser language doesn't match the page you landed on, a thin banner offers to switch you over.

Click a column header in the Dashboard to sort it. Works on Activity, API Keys, and sessions, survives the auto-refresh, and Ctrl-click (Cmd on Mac) clears the choice. The sidebar also collapses to an icon rail when you want the table to breathe.

Sites that wall requests behind an interactive challenge widget (the managed Turnstile pattern is the common one) now come back with rendered HTML when you call Browser with unblocker: true. Verified end-to-end against known-protected sites that were returning the challenge page before.

Pick your language from the globe in the header. The site and Playground now read in Bulgarian, Chinese, German, Polish, Vietnamese, and English, with locale-aware URLs you can bookmark or share.

We've tightened cross-origin access so only foura.ai can call the API with credentials. We also hardened an input filter on the metrics endpoint and dropped a development-only fallback secret. Existing integrations don't change.

If you've set validate.status.accept on a request, the engine treats an accepted non-200 as a clean success. Activity was still labeling those as failures, which threw off your usage stats. Outcomes now follow your validate verdict, so a 403 you accepted shows up as success, not App Fail.