Vérifications de sites

Lorsqu'une cible exécute une vérification de bot sur le chemin menant à la page demandée, FourA vous en informe. Chaque request qui en rencontre une renvoie un champ indiquant le nom du système, si la vérification a été validée, et (en cas de succès) le clearance que vous pouvez réutiliser pour que le prochain appel l'ignore.

Cette page constitue la référence pour ces champs. Pour la stratégie, consultez Sites protégés.

Emplacement du champ

Endpoint	Champ	Présent lorsque
`POST /api/single/`	`defense` (object)	Une vérification de bot a été détectée dans la response
`POST /api/proxy/`	`defense` (object)	Identique, rapporté par la tentative qui a répondu
`POST /api/browser/`	`defenseSolved` (boolean) et `defenses` (object)	Toujours, sur une page chargée. `defenseSolved` vaut `false` et `defenses` est vide lorsque rien n'a été détecté.
`POST /api/auto/`	`meta.solved` (boolean)	Sur chaque réponse dès que l'échelle a démarré. `true` lorsqu'une vérification a été validée quelque part sur l'échelle. Un corps non valide ou un hôte non résolu reçoit une réponse avant l'échelle, sans `meta`.

L'absence signifie que rien n'a été détecté. Ne considérez pas un defense manquant comme un échec.

Sur Single et Proxy, la détection nécessite unblocker, qui est activé par défaut. Avec unblocker: false, vous avez demandé la page exactement telle qu'elle a été reçue, donc Single renvoie le challenge intact et Browser l'affiche sans le résoudre.

`defense` sur Single et 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>"
  }
}

Champ	Type	Description
`vendor`	string	Le système concerné par cet enregistrement : celui qui a été validé ou le principal rencontré. Consultez la liste des fournisseurs ci-dessous.
`solved`	boolean	`true` signifie que la vérification a réussi et que `data` est la page réelle. `false` signifie que `data` peut être la page de défi.
`present`	string[]	Tous les systèmes reconnus sur cette réponse. Peut contenir plus de noms que `vendor`, ainsi que des noms que personne ne valide encore.
`ms`	number	Millisecondes passées à résoudre la vérification. Présent uniquement en cas de succès.
`hashes`	number	Quantité de travail de calcul demandée par le défi. Présent uniquement en cas de succès.
`complexity`	number	La difficulté déclarée par le défi. Présent uniquement en cas de succès et seulement lorsque le défi en signale une.
`answers`	number	Nombre de réponses acceptées fournies, pour les défis qui en exigent plusieurs au lieu d'une seule. Présent uniquement en cas de succès.
`retry`	string	Présent lorsque le corps provient d'une nouvelle tentative plutôt que d'une résolution. Aujourd'hui, la seule valeur est `refusal-cookies`. Voir ci-dessous.
`cookie`	string	Le cookie jar à rejouer : l'autorisation obtenue lors d'une validation ou la session transmise lors d'un refus.

solved: false est le cas sur lequel créer une branche conditionnelle. FourA ne présente jamais une page de défi comme du contenu, cet indicateur signale donc que le corps nécessite une escalade plutôt qu'une analyse.

`retry: "refusal-cookies"`

Certains sites n'exécutent aucun puzzle. Ils refusent la première requête, définissent des cookies lors du refus et servent la page réelle à quiconque renvoie ces cookies. Les pages d'articles d'eBay constituent le cas de référence.

Lorsque cela se produit, FourA les renvoie pour vous et vous transmet la page. La réponse contient alors retry: "refusal-cookies" :

{
  "status": 200,
  "data": "<!doctype html>...",
  "defense": {
    "vendor": "akamai",
    "solved": false,
    "present": ["akamai"],
    "retry": "refusal-cookies",
    "cookie": "bm_sv=...; dp1=..."
  }
}

Interprétez-le ainsi :

solved reste false. Répondre à un handshake ne constitue pas la résolution d'un challenge, et cela ne modifie jamais le coût de l'appel. Vous êtes facturé pour la request que vous avez effectuée.
data est le contenu réel, pas une page de challenge. C'est le seul cas où solved: false ne signifie pas que le body nécessite une escalade, c'est pourquoi ce champ existe.
cookie est la session délivrée par le site. Rejouez-la de la même manière que vous rejoueriez une validation et les pages suivantes éviteront le refus.
Un retry et une résolution peuvent tous deux se produire sur une même request. Si la réponse du retry s'est révélée être un challenge que FourA peut résoudre, vous obtenez solved: true avec les champs propres au fournisseur et retry: "refusal-cookies" à côté d'eux.

vendor indique unknown lorsqu'un retry a produit le contenu et qu'aucun système n'a été reconnu en cours de route. present est alors un tableau vide.

`defenses` sur Browser

{
  "status": 200,
  "body": "<!doctype html>...",
  "userAgent": "Mozilla/5.0...",
  "defenseSolved": true,
  "defenses": {
    "present": ["cloudflare"],
    "cleared": ["cloudflare"]
  }
}

Champ	Type	Description
`defenseSolved`	boolean	`true` lorsqu'un système a été rencontré pendant le chargement et que son autorisation est conservée sur la page finale. Il s'agit de l'indicateur qui détermine si l'appel coûte 5 ou 10 crédits.
`defenses.present`	string[]	Chaque système identifié à n'importe quel moment du chargement de la page, et pas seulement sur la réponse finale. Une vérification est un événement survenu, et au moment où la page réelle arrive, la réponse du challenge a disparu depuis longtemps.
`defenses.cleared`	string[]	Les systèmes dont la page finale conserve l'autorisation.

Un nom dans present qui n'apparaît jamais dans cleared correspond à un système que FourA sait identifier mais ne peut pas encore résoudre. Ceux-ci n'augmentent jamais le prix d'un appel.

Fournisseurs

Valeur `vendor`	Le système
`cloudflare`	Challenges Cloudflare et gestion des bots
`sgcaptcha`	Vérification de site de SiteGround
`datadome`	DataDome
`perimeterx`	PerimeterX
`akamai`	Akamai Bot Manager
`incapsula`	Imperva Incapsula
`awswaf`	Challenge AWS WAF
`ebay-splashui`	Propre challenge d'eBay
`reddit`	Pages de vérification et de refus propres à Reddit
`amazon`	Vérification de robot d'Amazon
`google`	Vérification JavaScript de Google Search
`hcaptcha`	hCaptcha
`recaptcha`	reCAPTCHA
`unknown`	Aucun système n'a été reconnu. N'apparaît qu'aux côtés de `retry`, où l'enregistrement existe pour signaler la nouvelle tentative plutôt qu'un fournisseur.

Ce qui est résolu aujourd'hui

Endpoint	Résout
Single, Proxy	`sgcaptcha`, `ebay-splashui`. Les deux sont computationnels plutôt que visuels, aucun navigateur n'est donc impliqué.
Browser	`cloudflare`, `sgcaptcha`

Tout le reste de la liste est identifié et signalé, rien de plus. Cette répartition évolue à mesure que FourA apprend à en résoudre davantage, lisez donc solved plutôt que de vous fier à cette table.

Deux remarques sur les cas particuliers :

hcaptcha et recaptcha sont aussi des widgets de formulaire ordinaires. Ils ne sont signalés que lorsque la réponse vous a réellement bloqué (403, 429 ou 503), donc une page de commande contenant un widget de vérification dans un formulaire ne signale aucune défense.
Être derrière Cloudflare ne constitue pas une défense. cloudflare apparaît lorsqu'il y a un réel challenge ou un artefact de gestion de bots dans la réponse, et non pas simplement parce qu'un site utilise Cloudflare.

Rejouer une autorisation

defense.cookie est la raison d'être de ce champ. Une autorisation est liée à la sortie et au User-Agent qui l'ont obtenue, rejouez-la donc avec la même combinaison pour que la vérification ne s'exécute pas à nouveau.

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"])

Le premier appel supporte le coût du déblocage. Chaque rejeu est une requête ordinaire au tarif ordinaire.

Trois éléments peuvent invalider un rejeu :

Une sortie différente. Épinglez l'ID de proxy renvoyé par la réponse de déblocage. Consultez Reuse a Proxy Across Requests.
Un User-Agent différent. Les réponses Browser renvoient le userAgent utilisé. Renvoyez-le avec le cookie.
L'expiration. Les autorisations ont leur propre durée de validité, définie par la cible. Celle de SiteGround dure environ 30 jours pour l'ensemble du site ; une autorisation Cloudflare est généralement beaucoup plus courte. Traitez une autorisation comme un cache : lorsque les rejeux recommencent à renvoyer des challenges, effectuez un nouvel appel pour obtenir une nouvelle autorisation.

Tarification

Une vérification résolue ne modifie le prix que sur Browser :

Engine	Base	Cleared defense
Single	1 (2 avec `unblocker`)	Aucun changement
Proxy	2 (4 avec `unblocker`)	Aucun changement
Browser	5	10

Browser facture 10 uniquement lorsque le solver était activé et qu'un système a réellement été résolu. Un système reconnu mais non résolu coûte 5, soit le même tarif qu'une page sans aucune vérification.

Une page de vérification reconnue par FourA et renvoyée avec le code HTTP 200 (par exemple le robot check d'Amazon, la page de vérification de Reddit ou le test JavaScript de Google Search) n'est facturée sur aucun endpoint ; la réponse l'indique dans X-FourA-Check-Page.

Associez-le avec `validate`

defense vous indique qu'une vérification a été rencontrée. validate indique à FourA à quoi ressemble la vraie page, ce qui permet à une requête d'échouer plutôt que de vous renvoyer une page intermédiaire portant par hasard un statut HTTP 200.

{
  "method": "GET",
  "url": "https://example.com/product/42",
  "validate": {
    "data": {"accept": ["Add to cart"], "fail": ["Just a moment"]}
  }
}

Sur POST /api/auto/, validate empêche l'algorithme d'accepter une page de challenge et de la considérer comme traitée.

Liens associés

Sites protégés : Quel moteur choisir selon le niveau de protection
Endpoints API : Référence des requêtes et réponses pour les quatre endpoints
Réutiliser un proxy entre les requêtes : Épingler la sortie à laquelle une autorisation est liée
Smart Fetch (Auto) : Comment meta.solved s'intègre dans le système d'escalade
Headers de réponse : Où apparaît le coût en crédits d'un appel

Mis à jour : 30 septembre 2026