Les règles de validation décident désormais de ce qui constitue un succès

Les règles validate de votre request déterminent désormais la classification de chaque résultat. Déclarez un code 403 comme acceptable, et un 403 délivré sera comptabilisé comme un succès, facturé comme tel, et apparaîtra dans votre flux Activity aux côtés de vos codes 200.

Cela semble mineur. Pourtant, cela change la façon dont vous mesurez la précision du scraping à grande échelle.

Comment ça marche

Chaque request envoyée à FourA reçoit l'un des sept résultats qui déterminent la facturation et les analyses. Seul le résultat success est facturable. Les autres se répartissent selon la responsabilité de l'échec :

• application_fail et application_error lorsque le site cible a refusé la requête ou a renvoyé un corps d'erreur
• client_error lorsque la request que vous avez envoyée était malformée
• service_fail, service_error et rate_limit lorsque quelque chose de notre côté a bloqué la request

Avant ce changement, un succès signifiait exactement une chose : un code HTTP 200. Un 403 était toujours classé en application_fail, même si vous saviez que ce 403 était la response attendue. (Certaines API de données sportives renvoient un 403 pour les marchés géo-bloqués, et c'est précisément le signal qu'attend votre code.)

Désormais, c'est votre bloc validate qui décide. La request applique vos règles lors de son exécution. Si la response les respecte, le résultat est success.

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/api/feed",
    "unblocker": true,
    "validate": {
      "status": { "accept": [200, 403] },
      "data": { "fail": ["captcha", "Access Denied"] }
    }
  }'

Cela traite les codes 200 et 403 comme des codes d'état valides. Si le corps de la réponse contient un marqueur de CAPTCHA ou une chaîne de caractères d'accès refusé, la request échoue. Tout le reste est un success.

Deux règles à retenir :

1. Sans validate, le comportement reste inchangé. Les request qui ne déclarent pas de validation restent facturées uniquement sur un code HTTP 200. L'activation est volontaire.
2. validate fonctionne dans les deux sens. Les règles d'acceptation valident, les règles d'échec rejettent. Elles se combinent. Vous pouvez donc accepter [200, 403] tout en échouant si le corps contient un contenu indésirable.

Impact

Ce changement est particulièrement important pour les équipes dont les cibles renvoient des response non-200 qu'elles souhaitent réellement obtenir.

Exemples de request que nous voyons quotidiennement :

• Des API de données sportives qui renvoient un 403 pour les marchés géo-bloqués (des données toujours utiles, qu'il convient de journaliser comme un succès)
• Des endpoint de recherche e-commerce qui renvoient un 404 lorsqu'une référence (SKU) est en rupture de stock (un signal lu par votre code, pas un échec)
• Des API de streaming et de contenu partiel qui renvoient un 206

Avant ce changement, ces équipes devaient effectuer leur propre suivi en plus de nos journaux d'activité Activity. Elles ne pouvaient pas se fier à la colonne outcome car leur définition du succès ne correspondait pas à la nôtre. Elles étaient facturées sur la base d'un chiffre qui ne les intéressait pas réellement.

Désormais, cette colonne reflète la réalité. L'onglet Activity de votre Dashboard affiche ce que vous avez défini comme un succès, et non ce que nous avons deviné. Vos totaux facturés correspondent à ce que vous comptabiliseriez vous-même (précision : ce changement s'applique uniquement pour l'avenir, les anciennes lignes d'activité Activity conservent donc leur classification d'origine).

L'effet pratique sur une tâche de scraping : moins d'étapes de réconciliation entre votre pipeline et notre facture. Si vous effectuiez déjà une validation sur le corps de la response après coup, vous pouvez désormais intégrer cette logique directement dans la request elle-même et cesser de maintenir un ensemble parallèle de règles de réussite/échec en dehors de notre API. Une seule définition pour déterminer si une request mérite sa place dans votre jeu de données, au lieu de deux définitions contradictoires.

But we kept the safety net. If you don't pass a validate block, nothing changes. The classifier falls back to "200 means success" so requests that worked yesterday work the same way today.

Pour les utilisateurs avancés

validate accepte trois ensembles de règles qui s'exécutent indépendamment : status, headers et data. Chacun accepte des listes optionnelles accept et fail.

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/product/9876",
    "followRedirects": 5,
    "unblocker": true,
    "validate": {
      "status": { "accept": [200, 304] },
      "headers": { "accept": { "content-type": "application/json" } },
      "data": { "accept": ["\"price\""], "fail": ["maintenance", "captcha"] }
    }
  }'

Cela nécessite :

• Que le statut soit 200 ou 304
• Que la response indique un type de contenu JSON
• Que le corps contienne un champ de prix
• Que le corps ne contienne pas d'avis de maintenance ni de piège CAPTCHA

Si une règle échoue, le résultat est application_fail. Si tout passe, c'est un success. Le classificateur s'exécute au sein même de la request, ce qui vous évite l'aller-retour qu'aurait coûté une étape de validation distincte.

Combiné avec followRedirects : suivez jusqu'à cinq redirections, puis validez la response finale. Une redirection trompeuse d'une URL propre vers une barrière CAPTCHA échoue proprement au lieu de polluer votre jeu de données.

Et un conseil issu de l'exécution de nos propres scrapers : déclarez les motifs data.fail de manière agressive. Un code 200 OK contenant un CAPTCHA est le mode d'échec silencieux le plus courant sur les sites protégés. Traitez le corps de la réponse comme faisant autorité, et non le code d'état.

Pour obtenir le schéma complet, la référence de la request répertorie chaque champ de validate et la manière dont ils se combinent.

Et ensuite ?

Nous travaillons sur des primitives de règles plus riches : des comparateurs regex pour data, des prédicats JSON-path structurés et une correspondance d'en-têtes plus souple. Le principe reste le même. Vous déclarez à quoi ressemble un succès ; l'API le respecte de bout en bout, de la request jusqu'à votre facture.

Quand votre scraper tombe en panne, cela doit se voir clairement. Et quand il fonctionne conformément aux règles que vous avez vous-même écrites, c'est un chiffre auquel vous pouvez réellement faire confiance.