← Tous les articles
Mise à jour produit 5 min de lecture

Les règles de validation définissent désormais le succès

Déclarez quelles réponses comptent comme un succès avec les règles de validation. Les réponses non-200 acceptées sont facturées correctement et s'affichent comme succès dans votre flux d'activité.

apivalidationoutcomesbilling

Les règles validate de votre request déterminent désormais la classification de chaque résultat. Déclarez un 403 comme acceptable, et un 403 reçu est comptabilisé comme un succès, facturé comme un succès, et apparaît dans votre flux d'activité aux côtés de vos 200.

Cela semble minime. Cela change pourtant la façon dont vous mesurez la précision de votre scraping à grande échelle.

Comment cela fonctionne

Chaque request envoyée à FourA reçoit l'un des sept résultats qui déterminent la facturation et les analyses. Seul success est facturable. Le reste est réparti selon la responsabilité de l'échec :

  • application_fail et application_error lorsque le site cible a refusé ou renvoyé un corps d'erreur
  • client_error lorsque la request envoyée était malformée
  • service_fail, service_error et rate_limit lorsque le blocage provient de notre côté

Avant ce changement, le succès ne signifiait qu'une seule chose : HTTP 200. Un 403 était toujours 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 soumis à des restrictions géographiques, et c'est précisément le signal attendu par votre code.)

Désormais, votre bloc validate décide. La request applique vos règles pendant l'exécution. Si la response les satisfait, le résultat est success.

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "X-API-Key: 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 200 et 403 comme des codes d'état valides. Si le body contient un marqueur de page de vérification ou une chaîne signalant un accès refusé, la request échoue. Tout le reste est success.

Deux règles à retenir :

  1. Sans validate, le comportement reste inchangé. Les requests qui ne déclarent pas de validation continuent d'être facturées uniquement sur un code HTTP 200. L'activation est explicite.
  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 déclenchant un échec si le body contient un contenu incorrect.

Impact

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

Exemples tirés des requests que nous traitons quotidiennement :

  • Des API de données sportives qui renvoient une 403 pour les marchés soumis à des restrictions géographiques (données toujours utiles, à enregistrer comme un succès)
  • Des endpoints de recherche e-commerce qui renvoient une 404 lorsqu'un SKU est en rupture de stock (un signal que votre code interprète, pas un échec)
  • Des API de streaming et de contenu partiel qui renvoient une 206

Avant cette modification, ces équipes devaient recalculer leurs propres métriques en plus de nos logs 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 une base qui ne reflétait pas leurs critères.

Désormais, la 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 une estimation de notre part. Vos totaux facturés correspondent à vos propres calculs (note : le changement s'applique uniquement aux nouveaux événements, les anciennes lignes d'Activity conservent leur classification d'origine).

L'effet pratique sur un job de scraping : moins d'étapes de réconciliation entre votre pipeline et notre facture. Si vous validiez déjà le body de la response a posteriori, vous pouvez désormais intégrer ce contrat directement dans la request et cesser de maintenir des règles de validation parallèles hors de notre API. Une seule définition pour déterminer si une request est valide, au lieu de deux qui divergent.

Nous avons toutefois conservé le filet de sécurité. Si vous ne transmettez pas de bloc validate, rien ne change. Le classificateur applique la règle par défaut "200 signifie succès", de sorte que les requests fonctionnelles d'hier fonctionnent à l'identique aujourd'hui.

Pour les utilisateurs avancés

validate accepte trois jeux 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 "X-API-Key: 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 :

  • Le statut est 200 ou 304
  • La response annonce un Content-Type JSON
  • Le body contient un champ price
  • Le body ne contient pas d'avis de maintenance ni de page de vérification

Si une règle échoue, le résultat est application_fail. Si tout réussit, c'est success. Le classificateur s'exécute au sein de la request elle-même, vous évitant ainsi l'aller-retour qu'imposerait une étape de validation séparée.

Combiné avec followRedirects : suivez jusqu'à cinq sauts, puis validez la response finale. Une redirection trompeuse d'une URL saine vers une page de vérification échoue proprement au lieu de polluer votre jeu de données.

Et un conseil issu de l'exploitation de nos propres scrapers : déclarez les motifs data.fail de manière agressive. Un code 200 OK masquant une page de vérification constitue le mode d'échec silencieux le plus courant sur les sites protégés. Fiez-vous au body, pas au code de statut.

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

Et ensuite

Nous travaillons sur des primitives de règles plus riches : des correspondances par expressions régulières pour data, des prédicats JSON-path structurés et une correspondance d'headers plus souple. Le principe reste identique. Vous définissez ce qui constitue un succès ; l'API le respecte de bout en bout, de la request jusqu'à votre facture.

Lorsque votre scraper casse, il doit le signaler clairement. Et lorsqu'il fonctionne selon les règles que vous avez vous-même définies, c'est un résultat auquel vous pouvez réellement vous fier.