Résultats des requêtes

Chaque request adressée à l'API FourA est classée dans un seul résultat. Le résultat est calculé une fois au moment de la request et enregistré pour votre clé API. Votre dashboard, votre flux d'activité et votre facturation lisent tous ce même champ.

Seul success est facturable.

Les sept résultats

Résultat	Couche	Signification
`success`	n/a	Une response valide a été délivrée. Comptabilisé dans votre quota facturable.
`application_error`	target	La cible a renvoyé un HTTP 200, mais le corps contenait un champ d'erreur.
`application_fail`	target	La cible a renvoyé un code non-2xx que vos règles `validate` n'ont pas accepté, ou aucune response.
`client_error`	caller	Votre request a été rejetée avant de quitter FourA. Paramètres incorrects, valeur proxy malformée, URL protégée contre le SSRF.
`rate_limit`	FourA	Votre limite de RPM ou de requêtes simultanées a été atteinte.
`service_error`	FourA	Le backend a renvoyé un 5xx, ou son corps n'était pas un JSON valide.
`service_fail`	FourA	Échec réseau : timeout, connexion refusée, erreur DNS, déconnexion du client.

La colonne de la couche vous indique qui est responsable :

Les résultats target concernent le site que vous avez appelé. Votre request a bien atteint FourA, et FourA a bien atteint la cible. La cible elle-même a renvoyé une erreur.
Les résultats caller signifient que votre request n'a jamais eu de chance d'aboutir. Corrigez la structure de la request.
Les résultats FourA sont de notre ressort. Réessayez, et consultez la page de statut s'ils persistent.

Un site cible renvoyant un 403 correspond à un application_fail, et non à un client_error. Votre appel était bien formé. Le site a simplement refusé.

Le succès prend en compte `validate`

Sans validate, l'API marque une request comme success uniquement lorsque la cible renvoie un HTTP 200.

Avec validate, le succès suit les règles que vous avez déclarées. Si vous indiquez à l'API que 200 et 403 sont tous deux acceptables pour une request donnée, un 403 est renvoyé comme success. Le corps vous parvient tout de même inchangé.

curl -X POST https://eu.api.foura.ai/api/single/ \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "method": "GET",
    "url": "https://target.example/feed",
    "validate": {
      "status": { "accept": [200, 403] }
    }
  }'

Dans cet appel, une response 403 est comptabilisée comme success et facturée comme une seule request. Une response 500 est comptabilisée comme application_fail et n'est pas facturée.

La même logique s'applique à validate.headers et validate.data. Toute response que le moteur accepte par rapport à vos règles est renvoyée comme success, quel que soit le statut HTTP.

Implications sur la facturation

Résultat	Facturable	Compté dans le quota
`success`	Oui	Oui
`application_error`	Non	Non
`application_fail`	Non	Non
`client_error`	Non	Non
`rate_limit`	Non	Non
`service_error`	Non	Non
`service_fail`	Non	Non

Seules les requests ayant fourni les données demandées sont facturées. Les échecs du côté de FourA, du côté de la cible ou de votre propre côté sont tous gratuits.

Lire les résultats dans le Dashboard

Chaque request effectuée par votre clé API apparaît dans le flux d'activité Activity avec son libellé de résultat. Les pages Metrics et Overview agrègent ce même champ pour les graphiques en anneau et les chronologies.

Lorsque vous filtrez l'activité par résultat, vous pouvez également vous concentrer sur un seul produit (Single, Proxy, Browser) pour voir si une classe d'échec est spécifique à un endpoint particulier.

Heuristiques de retry

Une politique de retry de premier niveau basée sur les résultats :

Résultat	Retry sans risque ?	Quand
`success`	n/a	Vous avez la response.
`application_error`	Parfois	Lisez le corps d'erreur de la cible. Certaines sont temporaires, la plupart ne le sont pas.
`application_fail`	Parfois	Si la cible applique un rate limit, ralentissez. Si elle vous bloque, passez à l'endpoint Proxy ou Browser.
`client_error`	Non	La request échouera à nouveau de la même manière. Corrigez les données d'entrée.
`rate_limit`	Oui	Respectez le `retryAfter` du corps de la response.
`service_error`	Oui	Court backoff exponentiel.
`service_fail`	Oui	Identique à `service_error`.

Voir aussi

API Errors : responses d'erreur au niveau HTTP
Rate Limits : ce qui déclenche un rate_limit
Metrics : où vous pouvez voir la répartition des résultats
Activity Log : historique des résultats par request

Mis à jour : 18 juin 2026