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

Présentation d'Auto : un seul endpoint pour toutes vos cibles

L'endpoint Auto choisit Single, Proxy Finder ou Browser pour chaque request, gère les défis anti-bot et renvoie une session que votre prochain appel peut réutiliser.

autoapiorchestrationsessionsanti-bot

Nouveautés

L'endpoint /api/auto est désormais le chemin le plus court pour obtenir une réponse fonctionnelle pour n'importe quelle URL. Pointez-le vers une cible. Auto choisit d'exécuter la request via Single, Proxy Finder ou Browser, gère les challenges anti-bot lorsqu'il en rencontre un, et renvoie une session que votre prochain appel peut réutiliser.

Un seul endpoint. N'importe quelle cible. Aucun changement de mode de votre côté.

C'est tout le principe. La suite de cet article explique son fonctionnement, son coût et ses limites.

Fonctionnement

Sous Auto se trouve une échelle d'échelons (du moins cher au plus cher). À chaque request, Auto gravit les échelons jusqu'à ce que l'un d'eux fournisse une response acceptée par vos règles validate.

Les échelons, dans l'ordre :

  1. Session en cache. Si Auto dispose d'une session active pour cet hôte issue d'un appel précédent, il rejoue la requête à travers celle-ci en priorité. Le chemin le plus économique.
  2. Proxy Finder. Une request avec proxy rotatif. Efficace pour les sites protégés principalement par la réputation d'IP.
  3. Browser. Un rendu complet qui exécute le JavaScript, résout les challenges anti-bot et collecte les cookies émis par le site.

Dès qu'un échelon réussit, Auto stocke la session trouvée : l'identifiant de proxy utilisé, les cookies émis par le site et le User-Agent. Lors du prochain appel vers le même hôte, Auto tente d'abord cette session. Si elle fonctionne toujours, vous payez l'échelon économique, pas l'échelon coûteux.

Un appel minimal :

curl -X POST "https://api.foura.ai/api/auto" \
  -H "X-API-Key: pk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/data",
    "validate": { "status": { "accept": [200] } }
  }'

Une réponse tronquée :

{
  "status": 200,
  "data": "...",
  "headers": [...],
  "meta": {
    "rung": "cache",
    "solved": false,
    "attempts": 1,
    "credits": 2
  },
  "session": {
    "proxy": "CLN1B8",
    "cookies": [{ "name": "cf_clearance", "value": "..." }],
    "userAgent": "..."
  }
}

Deux champs sont essentiels pour la suite de vos développements. meta.rung vous indique quel chemin l'a emporté. session est le triplet que vous pouvez transmettre à un appel /api/single pour rejouer vous-même la même sortie. Le champ proxy est un identifiant opaque en base36 (aucune IP brute), sans risque pour les logs et sûr à échanger entre systèmes.

Impact

Deux chiffres comptent ici.

Le premier appel vers un site protégé exécute le niveau Browser : rendu, résolution, collecte des cookies, remise de la page. Cela coûte environ 10 crédits. Dès que Auto a mis en cache une session fonctionnelle pour cet hôte, les appels suivants la rejouent : via Single à 2 crédits, ou via Proxy Finder à 4 crédits quand les cookies de la session fonctionnent depuis n'importe quelle adresse. Le deuxième appel est donc jusqu'à 5 fois moins cher que le premier, et chaque appel suivant continue de bénéficier du tarif réduit tant que la session reste valide. Nous avons mesuré cela en production lors du déploiement : les sorties sans cookies (une fois trouvées) se rejouent à exactement 2 crédits par appel, contre les 10 crédits qu'elles coûtaient auparavant quand chaque requête passait par Proxy Finder.

Le second chiffre : les niveaux en échec ne sont pas facturés. Si Auto teste trois proxys et que chacun renvoie une 403 avant que le quatrième ne réussisse, seuls les crédits du quatrième sont décomptés. Vous payez pour le contenu livré, pas pour la recherche.

C'est là l'avantage principal. Le niveau coûteux s'exécute une fois, le niveau économique prend le relais indéfiniment, et vous n'avez pas à écrire la logique de cache vous-même.

Deux autres comportements méritent d'être soulignés car ils résolvent de vraies difficultés en production :

Les cibles avec restriction géographique ne gaspillent plus de sorties. Lorsqu'un site renvoie une 451 (ou une page intermédiaire de blocage légal) pour la plupart des sorties, Auto apprend quels pays ont réellement livré du contenu. Lors de l'appel suivant, il sélectionne en priorité de nouvelles sorties issues de ces pays et répartit la charge concurrente entre elles. Une sortie qui a fonctionné par chance n'est donc pas surchargée ni soumise à un rate limit.

Validate s'exécute sur chaque niveau. Une page contenant un contenu incorrect (un blocage géographique renvoyant un statut 200 avec une notice légale dans le corps) n'est jamais comptabilisée comme un succès. Si votre validate.data.fail mentionne "legal reasons", Auto continue de chercher jusqu'à ce qu'un niveau valide la condition. Pas le niveau en cache. Aucun niveau intermédiaire. Si rien ne passe, vous obtenez un échec clair avec la cause réelle.

Pour les utilisateurs avancés

Quelques paramètres importants dès que vous envoyez du volume via Auto.

timeout_ms est un budget pour l'ensemble de l'opération, pas par niveau. La valeur par défaut est de 120 secondes. Auto le fractionne : chaque sous-appel reçoit min(son timeout naturel, le budget restant), et l'enchaînement cesse de lancer de nouveaux niveaux dès que le temps restant devient insuffisant. Définissez 20 000 pour les cas d'usage à latence interactive. Conservez la valeur par défaut pour les crawls volumineux qui tolèrent des délais plus longs.

forceProxy est activé par défaut. Auto ne contacte jamais la cible depuis l'IP d'origine de FourA, sauf si vous définissez forceProxy: false. Une mise en garde : certains sites (Cloudflare interactif avec filtrage basé sur la réputation IP) fonctionnent en réalité mieux depuis une IP de centre de données propre que depuis une sortie résidentielle à faible réputation. Ainsi, forceProxy: false peut rendre certaines cibles plus accessibles, et non l'inverse. Si vous observez des challenges répétés sur un hôte spécifique, désactiver cette option mérite d'être testé.

ignoreProxies est une liste d'exclusion côté client. Transmettez les identifiants de proxy que vous savez brûlés (issus d'une session.proxy précédente ayant subi un rate limit de votre côté), et Auto les ignore partout : réutilisation de sessions chaudes, recherche de sortie et sous-appel à Proxy Finder. Ainsi, Auto ne sélectionnera pas à nouveau la sortie que vous venez de lui demander d'éviter.

meta vous permet également de créer vos propres tableaux de bord : quels hôtes ont atteint le palier navigateur aujourd'hui, moyenne des tentatives par livraison, ratio des requêtes avec challenge résolu par rapport aux requêtes propres. Si un hôte spécifique passe soudainement de 2 crédits à 10, il s'agit d'un signal de dégradation de session que vous pouvez traiter avant que votre facture n'en subisse les conséquences.

Un exemple combinant ces quatre éléments :

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"X-API-Key": "pk_live_..."},
    json={
        "url": "https://example.com/product/9876",
        "timeout_ms": 30000,
        "forceProxy": True,
        "ignoreProxies": ["CLN1B8", "K7X9AB"],
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ['"price":'], "fail": ["captcha", "legal reasons"]}
        }
    }
).json()

# If Auto delivered, keep the session for the next call to this host
if r.get("status") == 200 and "session" in r:
    session = r["session"]                              # {proxy, cookies, userAgent}
    print(r["meta"]["rung"], r["meta"]["credits"], r["meta"]["attempts"])

Pour le schéma validate lui-même, consultez le guide précédent dans Validate Rules Now Decide What Counts as Success.

Prochaines étapes

Deux fonctionnalités sont actuellement sur la feuille de route pour Auto.

L'inspection des sessions arrive bientôt dans le Dashboard. Actuellement, les sessions qu'Auto conserve par hôte restent internes au service, et vous ne disposez d'aucun élément visuel pour déboguer une surconsommation depuis votre environnement. Nous intégrons une vue des sessions par hôte afin que vous puissiez examiner les sessions en cache, leur ancienneté, leur durée de vie restante et l'historique des paliers pour chacune d'elles. Vous disposerez également d'un bouton pour purger manuellement une session lorsque votre cible change et que vous savez que le cache est obsolète.

Ensuite, des contrôles de coûts plus stricts. Une limite stricte de crédits par requête (ne jamais dépenser plus de X sur cet appel, échouer proprement si ce seuil est dépassé) et un mode "single-only" pour les équipes dont les cibles ne nécessitent jamais le palier navigateur. Ces deux options sont aujourd'hui disponibles sous forme de flags.

L'intérêt d'Auto est de vous éviter de choisir quel produit appeler. Cela ne vous empêche pas pour autant d'inspecter ce qui s'est passé. Chaque réponse inclut le palier utilisé et la session générée. Consultez ces deux champs et vous saurez exactement pourquoi vos appels coûtent ce qu'ils coûtent.