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 requête via Single, Proxy Finder ou Browser, gère les vérifications de la page lorsqu'il en rencontre et renvoie une session réutilisable par votre prochain appel.
Un seul endpoint. N'importe quelle cible. Aucun changement de mode de votre côté.
C'est tout le concept. La suite de cet article explique son fonctionnement, son coût et ses limites techniques.
Fonctionnement
Sous Auto se trouve une échelle d'échelons (du moins cher au plus coûteux). À chaque requête, Auto monte les échelons jusqu'à ce que l'un d'eux fournisse une réponse acceptée par vos règles validate.
Les échelons, dans l'ordre :
- Session en cache. Si Auto dispose d'une session active pour cet hôte issue d'un appel précédent, il rejoue d'abord la requête avec celle-ci. Le chemin le plus économique.
- Proxy Finder. Une requête via un proxy avec rotation. Adapté aux sites protégés principalement par la réputation IP.
- Browser. Un rendu complet qui exécute le JavaScript, franchit les vérifications demandées par la page et collecte les cookies émis par le site.
Dès qu'un échelon réussit, Auto enregistre la session trouvée : l'id de proxy utilisé, les cookies émis par le site et le User-Agent. Lors du prochain appel vers le même hôte, Auto teste cette session en premier. Si elle fonctionne toujours, vous payez l'échelon économique, pas le plus cher.
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 importants pour la suite de vos développements. meta.rung vous indique quel chemin a fonctionné. session est le triplet que vous pouvez réutiliser dans 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 à transmettre entre vos systèmes.
Impact
Deux chiffres comptent ici.
Le premier appel vers un site protégé exécute le palier Browser : rendu, résolution, collecte des cookies, renvoi de la page. Cela coûte environ 10 crédits. Dès qu'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 cookie (une fois trouvées) se rejouent à exactement 2 crédits par appel, contre les 10 crédits qu'elles coûtaient lorsque chaque requête passait par Proxy Finder.
Le deuxième chiffre : les paliers qui échouent ne sont pas facturés. Si Auto essaie trois proxys et que chacun renvoie une 403 avant que le quatrième ne délivre le contenu, seuls les crédits du quatrième sont comptabilisés. Vous payez pour le contenu délivré, pas pour la recherche.
C'est là toute la valeur fondamentale. Le palier coûteux ne s'exécute qu'une fois, le palier économique prend le relais ensuite, et vous n'avez pas à écrire vous-même la logique de mise en cache.
Deux autres comportements méritent d'être soulignés car ils résolvent de vrais problèmes en production :
Les cibles avec restriction géographique ne gaspillent plus de sorties. Lorsqu'un site renvoie une 451 (ou un interstitiel de blocage légal) pour la plupart des sorties, Auto identifie les pays qui ont réellement délivré du contenu. Lors de l'appel suivant, il sélectionne en priorité de nouvelles sorties dans ces pays et répartit la charge concurrente entre elles. Une unique sortie fonctionnelle n'est donc pas surchargée ni soumise à un rate limit.
La validation s'exécute sur chaque palier. Une page au contenu incorrect (une restriction par pays qui renvoie 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 d'itérer jusqu'à ce qu'un palier valide le critère. Ni le palier en cache, ni aucun autre palier ne déroge à la règle. Si aucun palier ne passe, vous obtenez un échec clair avec la cause réelle.
Pour les utilisateurs avancés
Quelques réglages utiles dès que vous envoyez du volume via Auto.
timeout_ms est un budget global pour l'opération, pas un budget par palier. La valeur par défaut est de 120 secondes. Auto le répartit : chaque sous-appel reçoit min(son timeout naturel, le budget restant), et la séquence s'arrête de lancer de nouveaux paliers dès que le temps restant devient insuffisant. Définissez 20 000 pour des contraintes de latence interactive. Conservez la valeur par défaut pour les crawls de masse 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 nuance : certains sites (Cloudflare interactif avec contrôle de réputation IP) fonctionnent 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. 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'évitement côté client. Transmettez les identifiants de proxy que vous savez grillés (issus d'un session.proxy précédent qui a 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 de tentatives par livraison, ratio de requêtes avec challenge résolu par rapport aux requêtes directes. Si un hôte spécifique passe soudainement de 2 à 10 crédits, c'est un signal de dégradation de session sur lequel vous pouvez agir avant que votre facture ne s'alourdisse.
Voici 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 éléments 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, sans visibilité possible lors du débogage d'une consommation anormale de votre côté. Nous intégrons une vue des sessions par hôte afin de vous permettre de consulter les sessions en cache, leur ancienneté, leur durée de vie restante et l'historique des rungs associés. Vous disposerez également d'un bouton pour purger manuellement une session lorsque votre cible change et que le cache n'est plus valide.
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 proprement si ce seuil est dépassé) et un mode "single-only" pour les équipes dont les cibles ne nécessitent jamais le rung browser. Ces deux fonctionnalités sont actuellement sous flags.
L'objectif d'Auto est de vous éviter de choisir quel produit appeler. Cela ne vous empêche pas d'inspecter l'exécution. Chaque response inclut le rung emprunté et la session générée. Consultez ces deux champs pour comprendre précisément le coût de vos appels.