What's New
The /api/auto endpoint is now the shortest path to a working response for any URL. Point it at a target. Auto picks whether to run the request through Single, Proxy Finder, or Browser, handles anti-bot challenges when it hits one, and hands back a session your next call can reuse.
One endpoint. Any target. No mode-switching from your side.
That's the whole idea. The rest of this post is how it works, what it costs, and where the sharp edges are.
How It Works
Under Auto sits a ladder of rungs (cheap first, expensive last). On every request, Auto walks up the ladder until one rung delivers a response your validate rules accept.
The rungs, in order:
- Cached session. If Auto has a warm session for this host from a previous call, it replays through that first. Cheapest path.
- Proxy Finder. A rotated proxy request. Good for sites protected mainly by IP reputation.
- Browser. A full render that executes JavaScript, solves anti-bot challenges, and collects the cookies the site issues.
Once a rung wins, Auto stores the session it found: the proxy id it used, the cookies the site issued, and the User-Agent. On the next call to the same host, Auto tries that session first. If it still works, you pay the cheap rung, not the expensive one.
A minimal call:
curl -X POST "https://api.foura.ai/api/auto" \
-H "Authorization: Bearer pk_live_..." \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/data",
"validate": { "status": { "accept": [200] } }
}'
A trimmed response:
{
"status": 200,
"data": "...",
"headers": [...],
"meta": {
"rung": "cache",
"solved": false,
"attempts": 1,
"credits": 2
},
"session": {
"proxy": "CLN1B8",
"cookies": [{ "name": "cf_clearance", "value": "..." }],
"userAgent": "..."
}
}
Two fields matter for what you build next. meta.rung tells you which path won. session is the triple you can carry into a /api/single call to replay the same exit yourself. The proxy field is an opaque base36 id (no raw IPs), safe to log and safe to hand between systems.
Impact
Two numbers matter here.
The first call to a protected site runs the Browser rung: render, solve, collect cookies, hand you the page. That's about 10 credits. Once Auto has cached a working session for that host, follow-up calls run through Single at 2 credits. So the second call is 5x cheaper than the first, and every one after keeps paying the cheap rate as long as the session holds. We measured this on prod during rollout: no-cookie exits (once found) replay at exactly 2 credits per call versus the 10 they used to cost when every request went through Proxy Finder.
The second number: failed rungs don't bill. If Auto tries three proxies and each 403s before the fourth delivers, only the fourth's credits count. You pay for delivered content, not for the search.
That's the core value. The expensive rung runs once, the cheap rung runs forever after, and you don't have to write the caching logic yourself.
Two other behaviors are worth flagging because they solve real production headaches:
Geo-fenced targets stop wasting exits. When a site returns 451 (or a legal-block interstitial) for most exits, Auto learns which countries actually delivered content. On the next call it pulls fresh exits from those countries first and spreads concurrent load across them. So a single lucky exit doesn't get piled on and rate-limited.
Validate runs on every rung. A wrong-content page (a geo-block that returns status 200 with a legal notice as body) never counts as a hit. If your validate.data.fail says "legal reasons", Auto keeps grinding until a rung passes it. Not the cached rung. Not any rung. If nothing passes, you get an honest fail with the real reason.
For Power Users
A few knobs that matter once you push volume through Auto.
timeout_ms is a whole-operation budget, not a per-rung one. Default is 120 seconds. Auto portions it: every sub-call gets min(its natural timeout, the remaining budget), and the ladder stops launching new rungs once too little time is left. Set 20,000 for interactive latency work. Leave the default for bulk crawls that tolerate longer tails.
forceProxy is on by default. Auto never touches the target from FourA's origin IP unless you set forceProxy: false. One caveat: some sites (interactive Cloudflare with IP-trust gating) actually work better from a clean data-center IP than from a low-trust residential exit. So forceProxy: false can make certain targets easier, not harder. If you're seeing repeated challenges on a specific host, flipping this off is worth trying.
ignoreProxies is a client avoid-list. Pass proxy ids you know are burned (from a prior session.proxy that got rate-limited on your side), and Auto skips them everywhere: warm session reuse, exit search, and the sub-call to Proxy Finder. So Auto won't re-pick the exit you just told it to avoid.
meta also lets you build your own dashboards on top: which hosts hit the browser rung today, average attempts per delivery, ratio of solved-challenge fetches to clean ones. If a specific host suddenly climbs from 2 credits to 10, that's a session decay signal you can act on before your bill catches up.
An example that composes all four:
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"Authorization": "Bearer pk_live_..."},
json={
"url": "https://example.com/product/9876",
"timeout_ms": 30000,
"forceProxy": True,
"ignoreProxies": ["CLN1B8", "K7X9AB"],
"validate": {
"status": {"accept": [200]},
"data": {"accept": ['"price":'], "fail": ["captcha", "legal reasons"]}
}
}
).json()
# If Auto delivered, keep the session for the next call to this host
if r.get("status") == 200 and "session" in r:
session = r["session"] # {proxy, cookies, userAgent}
print(r["meta"]["rung"], r["meta"]["credits"], r["meta"]["attempts"])
For the validate schema itself, see the earlier walkthrough in Validate Rules Now Decide What Counts as Success.
What's Next
Two things are on the roadmap for Auto right now.
Session inspection lands in the Dashboard next. Right now the sessions Auto keeps per host live inside the service, and there's nothing to look at when you're debugging a burn from your side. We're wiring a per-host session view so you can see cached sessions, their ages, how long they'll live, and the rung history behind each one. Plus a button to drop a session by hand when your target changes and you know the cache is wrong.
After that, tighter cost controls. A hard per-request credit cap (never spend more than X on this call, fail honestly if you would) and a "single-only" mode for teams whose targets never need the browser rung. Both are behind flags today.
The point of Auto is that you don't think about which product to call. That doesn't mean you can't inspect what happened. Every response ships the rung it took and the session it built. Read those two fields and you'll know exactly why your calls cost what they cost.