Changelog

Credit usage warnings are paused until every account has its plan assigned. If you got a '100% used' notice, you can ignore it; nothing on your account changed.

Dropdowns, checkboxes, scrollbars, autofilled fields, and dialog buttons showed a light look on dark theme (white boxes, stray outlines). Now every control follows the active theme. Modals stop scrolling the page behind them, tooltips inside dialogs sit on top, and number inputs hide their spin buttons.

The PDF button on some paid invoices didn't render because we weren't setting the underlying link. Every paid invoice in the Invoices tab now has a working PDF button.

If you passed a negative validate to /api/auto (like {data: {fail: ['"Due to legal reasons"']}}), a Cloudflare 'Just a moment' interstitial could slip through as a cached success because the fail-list didn't happen to match its text. Auto now rejects challenge pages before applying your validate rules, and it swaps the bad exit and re-solves instead of scoring it.

If you set a long timeout on foura_auto through the hosted MCP server, the request could time out at the edge before your call finished. That's fixed. Full-budget auto calls now run their 180-second budget end to end.

If you've been hitting 429s when firing many concurrent Auto calls at one target, those calls used to funnel onto a single cached exit because the warm path picked the score-favourite and replayed once. Auto now opens additional sessions on demand and routes each call to the least-loaded exit, so a burst fans out across multiple proxy IDs instead of hammering one. Measured locally: a 100-call burst on a no-cookie portable host now spreads across the grown pool within seconds.

Cloudflare injects a passive script even on pages that pass cleanly, and Auto used to treat any reference to it as an active challenge and run a full browser solve anyway. Now only true interstitial markers (the 'just a moment' page and friends) trigger the browser path; a clean 200 comes back from the cheaper proxy rung. Auto also follows up to 5 redirects by default (configurable via followRedirects).

When a Cloudflare-protected target served a real geo-block page (451) after the challenge passed, the Browser product was reporting it as a 200 because the watcher hardcoded the cleared status. The watcher now reads the actual post-clearance Document, so a 200 stays 200, a 451 surfaces as 451, and Auto rejects the wrong content and keeps searching for an exit that genuinely matches your validate rules.

The Cmd+K (Ctrl+K) shortcut now opens the command palette and search modal regardless of keyboard layout. We were matching the typed character (к on a Cyrillic layout), so anyone on a non-Latin layout got nothing. Now we match the physical key. Fixed across the main site, the blog, and the docs.

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.

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.

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.

If you were scraping Cyrillic, Chinese, Japanese, or other non-UTF-8 pages through Single, the body used to come back as mojibake. We were force-decoding every response as UTF-8 before you saw the raw bytes. Now we read the charset from the response (Content-Type, then <meta charset>, then UTF-8 fallback) and decode it correctly. Thanks, Alexandar Kanchev (Sensika), for reporting this.

Some proxies in the wild don't actually forward your request. They echo it back as a plaintext server dump and try to harvest what's inside. We now spot that pattern before the response hits your code, so Single, Browser, and Proxy Finder all return an honest failure (or retry) instead of the garbage.