Anti-Bot Defenses
When a target runs a bot check on the way to the page you asked for, FourA tells you. Every request that meets one comes back with a field naming the system, whether the check was cleared, and (on a clear) the clearance you can replay so the next call skips it.
This page is the reference for those fields. For strategy, see Handling Anti-Bot Protection.
Where the Field Lives
| Endpoint | Field | Present when |
|---|---|---|
POST /api/single/ |
defense (object) |
A bot check was recognised on the response |
POST /api/proxy/ |
defense (object) |
Same, reported by the attempt that answered |
POST /api/browser/ |
defenseSolved (boolean) and defenses (object) |
A bot check was recognised during the page load |
POST /api/auto/ |
meta.solved (boolean) |
Always. true when a check was cleared somewhere on the ladder. |
Absence means nothing was recognised. Don't read a missing defense as a failure.
Reporting needs unblocker, which is on by default. With unblocker: false you asked for the page exactly as it came, so Single hands back the challenge untouched and Browser renders it without solving.
defense on Single and Proxy
{
"status": 200,
"data": "<!doctype html>...",
"total_time": 3.61,
"defense": {
"vendor": "sgcaptcha",
"solved": true,
"present": ["sgcaptcha"],
"ms": 3412,
"hashes": 1048576,
"complexity": 20,
"cookie": "_I_=<clearance>"
}
}
| Field | Type | Description |
|---|---|---|
vendor |
string | The system this record is about: the one that was cleared, or the main one met. See the vendor list below. |
solved |
boolean | true means the check was cleared and data is the real page. false means data may be the challenge page. |
present |
string[] | Every system recognised on this response. Can hold more names than vendor, and can hold names nobody clears yet. |
ms |
number | Milliseconds spent clearing the check. Only on a clear. |
hashes |
number | How much computational work the challenge asked for. Only on a clear. |
complexity |
number | The difficulty the challenge declared. Only on a clear, and only where the challenge reports one. |
answers |
number | How many accepted answers were supplied, for challenges that want several rather than one. Only on a clear. |
cookie |
string | The clearance the clear earned, ready to replay. Only on a clear. |
solved: false is the case worth branching on. FourA never presents an unsolved challenge as content, so the flag is your signal that the body needs escalation rather than parsing.
defenses on Browser
{
"status": 200,
"body": "<!doctype html>...",
"userAgent": "Mozilla/5.0...",
"defenseSolved": true,
"defenses": {
"present": ["cloudflare"],
"cleared": ["cloudflare"]
}
}
| Field | Type | Description |
|---|---|---|
defenseSolved |
boolean | true when a system was met during the load and its clearance is held on the final page. This is the flag that decides whether the call costs 15 or 30 credits. |
defenses.present |
string[] | Every system recognised at any point during the page load, not just on the final response. A check is something that happened, and by the time the real page arrives the challenge response is long gone. |
defenses.cleared |
string[] | The systems whose clearance the final page holds. |
A name in present that never reaches cleared is a system FourA can recognise but not yet get past. Those never raise the price of a call.
Vendors
vendor value |
The system |
|---|---|
cloudflare |
Cloudflare challenges and bot management |
sgcaptcha |
SiteGround's site check |
datadome |
DataDome |
perimeterx |
PerimeterX |
akamai |
Akamai Bot Manager |
incapsula |
Imperva Incapsula |
awswaf |
AWS WAF challenge |
ebay-splashui |
eBay's own challenge |
hcaptcha |
hCaptcha |
recaptcha |
reCAPTCHA |
What Gets Cleared Today
| Endpoint | Clears |
|---|---|
| Single, Proxy | sgcaptcha, ebay-splashui. Both are computational rather than visual, so no browser is involved. |
| Browser | cloudflare, sgcaptcha |
Everything else on the list is recognised and reported, and nothing more. That split moves as FourA learns to clear more of them, so read solved rather than assuming from this table.
Two notes on the edges:
hcaptchaandrecaptchaare also ordinary form widgets. They're only reported when the response actually blocked you (403, 429, or 503), so a checkout page with a captcha field in a form doesn't report a defense.- Being behind Cloudflare isn't a defense.
cloudflareappears when there's a real challenge or bot-management artifact on the response, not because a site uses Cloudflare.
Replaying a Clearance
defense.cookie is the whole point of the field. A clearance is bound to the exit that earned it and the User-Agent that earned it, so replay it through the same pair and the check doesn't run again.
import requests
API = "https://eu.api.foura.ai"
H = {"X-API-Key": "YOUR_API_KEY", "Content-Type": "application/json"}
# 1) First call pays for the clear.
first = requests.post(f"{API}/api/proxy/", headers=H, json={
"maxTries": 5,
"request": {"method": "GET", "url": "https://example.com/catalog"},
}).json()
defense = first.get("defense", {})
if defense.get("solved"):
clearance = defense["cookie"]
exit_id = first["proxy"]
# 2) Follow-up pages skip the check: same exit, same clearance.
for page in range(2, 6):
r = requests.post(f"{API}/api/single/", headers=H, json={
"method": "GET",
"url": f"https://example.com/catalog?page={page}",
"proxy": exit_id,
"headers": [["Cookie", clearance]],
}).json()
print(page, r["status"])
The first call carries the cost of the clear. Every replay is an ordinary request at the ordinary price.
Three things break a replay:
- A different exit. Pin the proxy ID the clearing response returned. See Reuse a Proxy Across Requests.
- A different User-Agent. Browser responses return the
userAgentthey used. Send it back with the cookie. - Expiry. Clearances have their own lifetimes, set by the target. SiteGround's runs around 30 days for the whole site; a Cloudflare clearance is usually much shorter. Treat a clearance as a cache: when replays start returning challenges again, run one fresh call and take the new one.
What It Costs
A cleared check changes the price on Browser only:
| Engine | Base | Cleared defense |
|---|---|---|
| Single | 1 (2 with unblocker) |
No change |
| Proxy | 5 (10 with unblocker) |
No change |
| Browser | 15 | 30 |
Browser charges 30 only when the solver was on and a system was genuinely cleared. A system that was recognised and not cleared costs 15, the same as a page with no check on it at all.
Pair It With validate
defense tells you a check was met. validate tells FourA what the real page looks like, which is what lets a request fail rather than hand you an interstitial that happens to carry HTTP 200.
{
"method": "GET",
"url": "https://example.com/product/42",
"validate": {
"data": {"accept": ["Add to cart"], "fail": ["Just a moment"]}
}
}
On POST /api/auto/, validate is what stops the ladder from accepting a challenge page and calling it done.
Related
- Handling Anti-Bot Protection: Which engine to reach for at each protection level
- API Endpoints: Request and response reference for all four endpoints
- Reuse a Proxy Across Requests: Pin the exit a clearance is bound to
- Smart Fetch (Auto): How
meta.solvedfits into the ladder - Response Headers: Where the credit cost of a call shows up