← 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 vers une response 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 défis 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 toute l'idée. Le reste de cet article explique comment cela fonctionne, ce que cela coûte et où se trouvent les limites.

Comment cela fonctionne

Sous Auto se trouve une échelle de niveaux (les moins chers d'abord, les plus chers ensuite). À chaque request, Auto gravit l'échelle jusqu'à ce qu'un niveau fournisse une response que vos règles validate acceptent.

Les niveaux, dans l'ordre :

  1. Session en cache. Si Auto dispose d'une session chaude pour cet hôte à partir d'un appel précédent, il rejoue d'abord via celle-ci. Le chemin le moins cher.
  2. Proxy Finder. Une request proxy avec rotation. Idéal pour les sites protégés principalement par la réputation IP.
  3. Browser. Un rendu complet qui exécute JavaScript, résout les défis anti-bot et collecte les cookies émis par le site.

Une fois qu'un niveau l'emporte, Auto stocke la session qu'il a trouvée : l'identifiant du proxy utilisé, les cookies émis par le site et le User-Agent. Lors de l'appel suivant au même hôte, Auto essaie d'abord cette session. Si elle fonctionne toujours, vous payez le niveau le moins cher, pas le plus cher.

Un appel minimal :

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

Une response 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 comptent pour ce que vous allez construire ensuite. meta.rung vous indique quel chemin a gagné. session est le triplet que vous pouvez transporter dans un appel /api/single pour rejouer la même sortie vous-même. Le champ proxy est un identifiant base36 opaque (pas d'IP brutes), sûr à journaliser et sûr à transmettre entre les systèmes.

Impact

Deux nombres comptent ici.

Le premier appel vers un site protégé exécute le niveau Browser : rendu, résolution, collecte des cookies, livraison de la page. Cela coûte environ 10 crédits. Une fois qu'Auto a mis en cache une session fonctionnelle pour cet hôte, les appels suivants passent par Single pour 2 crédits. Ainsi, le deuxième appel est 5 fois moins cher que le premier, et tous les suivants conservent ce tarif avantageux tant que la session est maintenue. Nous avons mesuré cela en production lors du déploiement : les sorties sans cookie (une fois trouvées) se rejouent à exactement 2 crédits par appel contre les 10 qu'elles coûtaient auparavant lorsque chaque request passait par Proxy Finder.

Le deuxième nombre : les niveaux en échec ne sont pas facturés. Si Auto essaie trois proxys et que chacun renvoie une erreur 403 avant que le quatrième ne livre le contenu, seuls les crédits du quatrième comptent. Vous payez pour le contenu livré, pas pour la recherche.

C'est la valeur fondamentale. Le niveau coûteux s'exécute une fois, le niveau bon marché s'exécute pour toujours ensuite, et vous n'avez pas à écrire la logique de mise en cache vous-même.

Deux autres comportements méritent d'être signalés car ils résolvent de véritables casse-têtes en production :

Les cibles géo-restreintes arrêtent de gaspiller les sorties. Lorsqu'un site renvoie 451 (ou un interstitiel 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 extrait d'abord de nouvelles sorties de ces pays et répartit la charge simultanée sur celles-ci. Ainsi, une seule sortie chanceuse ne subit pas d'accumulation ni de rate limit.

Validate s'exécute à chaque niveau. Une page avec un contenu erroné (un blocage géographique qui renvoie le statut 200 avec un avis légal comme corps) ne compte jamais comme un succès. Si votre validate.data.fail indique "legal reasons", Auto continue de chercher jusqu'à ce qu'un niveau la valide. Pas le niveau en cache. Pas n'importe quel niveau. Si rien ne passe, vous obtenez un véritable échec avec la raison réelle.

Pour les utilisateurs avancés

Quelques réglages qui comptent une fois que vous passez du volume via Auto.

timeout_ms est un budget pour l'opération complète, et non par niveau. Le défaut est de 120 secondes. Auto le répartit : chaque sous-appel obtient le minimum de (son délai d'attente naturel, le budget restant), et l'échelle arrête de lancer de nouveaux niveaux lorsqu'il reste trop peu de temps. Définissez 20 000 pour le travail de latence interactive. Laissez le défaut pour les explorations en masse qui tolèrent des queues plus longues.

forceProxy est activé par défaut. Auto ne touche jamais la cible depuis l'IP d'origine de FourA à moins que vous ne définissiez forceProxy: false. Une mise en garde : certains sites (Cloudflare interactif avec filtrage de confiance IP) fonctionnent en réalité mieux depuis une IP de centre de données propre que depuis une sortie résidentielle à faible confiance. Donc forceProxy: false peut rendre certaines cibles plus faciles, et non plus difficiles. Si vous rencontrez des défis répétés sur un hôte spécifique, il vaut la peine d'essayer de le désactiver.

ignoreProxies est une liste d'exclusion client. Passez les identifiants de proxy que vous savez bloqués (provenant d'une session.proxy antérieure ayant subi un rate limit de votre côté), et Auto les ignore partout : réutilisation de sessions à chaud, recherche de sortie, et le sous-appel à Proxy Finder. Ainsi, Auto ne sélectionnera pas à nouveau la sortie que vous venez de lui indiquer d'éviter.

meta vous permet également de créer vos propres tableaux de bord par-dessus : quels hôtes ont atteint l'échelon navigateur aujourd'hui, le nombre moyen de tentatives par livraison, le ratio de requêtes avec défi résolu par rapport aux requêtes propres. Si un hôte spécifique passe soudainement de 2 crédits à 10, c'est un signal de dégradation de session sur lequel vous pouvez agir avant que cela n'impacte votre facture.

Un exemple qui combine les quatre :

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer 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 l'explication précédente dans Validate Rules Now Decide What Counts as Success.

La suite

Deux éléments sont actuellement sur la feuille de route pour Auto.

L'inspection des sessions arrive ensuite dans le Dashboard. Actuellement, les sessions qu'Auto conserve par hôte se trouvent dans le service, et il n'y a rien à observer lorsque vous déboguez une consommation de votre côté. Nous préparons une vue des sessions par hôte afin que vous puissiez voir les sessions en cache, leur âge, leur durée de vie et l'historique des niveaux de chacune. S'y ajoute un bouton pour supprimer une session manuellement lorsque votre cible change et que vous savez que le cache est obsolète.

Ensuite, des contrôles de coûts plus stricts. Un plafond strict de crédits par request (ne jamais dépenser plus de X pour cet appel, échouer de manière transparente dans le cas contraire) et un mode "single-only" pour les équipes dont les cibles n'ont jamais besoin du niveau navigateur. Ces deux fonctionnalités sont aujourd'hui sous flags.

Le principe d'Auto est que vous n'avez pas à réfléchir au produit à appeler. Cela ne signifie pas que vous ne pouvez pas inspecter ce qui s'est passé. Chaque response renvoie le niveau utilisé et la session créée. Lisez ces deux champs et vous saurez exactement pourquoi vos appels coûtent ce qu'ils coûtent.