Choisir le bon endpoint

FourA propose quatre endpoints de request, chacun optimisé pour un scénario différent. Choisir le bon vous fait gagner du temps, réduit les coûts et améliore les taux de réussite.

Guide de décision rapide

Utilisez l'endpoint auto lorsque :

  • Vous ciblez un nouveau site et vous ne savez pas encore ce dont il a besoin
  • Vous voulez un seul appel qui gère pour vous les replis directs, avec rotation de proxy et par navigateur
  • Vous voulez une session que vous pouvez rejouer à moindre coût lors du prochain appel vers le même hôte

Utilisez l'endpoint single lorsque :

  • La page est générée côté serveur (aucun JavaScript requis)
  • Vous avez besoin d'une vitesse maximale (généralement moins de 1 seconde)
  • Vous interrogez des API ou des pages HTML statiques depuis un hôte dont vous savez déjà qu'il fonctionne

Utilisez l'endpoint browser lorsque :

  • La page dépend de JavaScript pour afficher le contenu
  • Le contenu se charge après le chargement initial de la page
  • Vous avez besoin du DOM entièrement rendu

Utilisez l'endpoint proxy lorsque :

  • Le site cible bloque activement les requêtes
  • Vous devez alterner entre plusieurs adresses IP
  • Les tentatives précédentes ont renvoyé des erreurs 403 ou des pages de vérification

Comparaison des endpoints

Auto (POST /api/auto/)

L'endpoint de smart-fetch. Vous transmettez une URL et (idéalement) une règle validate, et FourA suit une hiérarchie optimisée selon les coûts : d'abord un proxy rotatif, puis un navigateur complet via un proxy. Définissez forceProxy: false et un test direct économique ainsi qu'un rendu direct par navigateur s'exécutent avant ces deux étapes. Le premier niveau qui renvoie une réponse correspondant à votre validate l'emporte. Lors des appels répétés vers le même hôte, une session active est rejouée, ce qui rend le second appel peu coûteux.

curl -X POST https://eu.api.foura.ai/api/auto/ \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/product/42",
    "validate": {"data": {"accept": ["Add to cart"]}}
  }'

Temps de réponse typique : 200 ms (à chaud) à 30 s+ (résolution à froid sur un site difficile) Idéal pour : Nouvelles cibles, sites à protection mixte, "je veux simplement la page"

Pour une présentation plus détaillée, consultez le guide Smart Fetch.

Single (POST /api/single/)

L'option la plus rapide. Envoie une requête HTTP avec des caractéristiques réseau réalistes similaires à celles d'un navigateur, sans lancer de processus de navigateur.

curl -X POST https://eu.api.foura.ai/api/single/ \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"method": "GET", "url": "https://example.com/api/products"}'

Temps de réponse typique : 200 ms à 2 s Idéal pour : API, sites d'actualités, blogs, pages produits statiques

Browser (POST /api/browser/)

Ouvre votre URL dans une instance de navigateur Chrome. La page se charge complètement, le JavaScript s'exécute, et vous obtenez le HTML final rendu.

curl -X POST https://eu.api.foura.ai/api/browser/ \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/spa-app",
    "timeout_ms": 15000,
    "checkText": "data-table"
  }'

Temps de réponse standard : 2s à 10s Idéal pour : Single-page apps (SPA), sites avec lazy loading, contenu généré via JavaScript

Proxy (POST /api/proxy/)

Combine des requêtes HTTP avec une rotation automatique des proxys. Si la première tentative échoue ou est bloquée, FourA réessaie via d'autres proxys.

curl -X POST https://eu.api.foura.ai/api/proxy/ \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "maxTries": 5,
    "request": {
      "method": "GET",
      "url": "https://example.com/pricing"
    }
  }'

Temps de réponse typique : 1s à 5s Idéal pour : Suivi des prix e-commerce, agrégation de voyages, sites avec détection de bots

Auto vs Manuel

Quand devez-vous laisser le mode auto choisir, et quand devez-vous appeler Single, Proxy ou Browser vous-même ?

Choisir auto Choisir manuel
Vous ne savez pas encore ce dont le site a besoin Vous savez exactement quel moteur la cible exige
Vous voulez un seul appel qui fonctionne directement Vous optimisez la structure de la requête pour une cible connue
La réutilisation par auto d'une session apprise vous convient Vous voulez un contrôle total sur les retries par appel, le timeout et le choix du proxy
Vous acceptez quelques secondes de probing lors du premier appel La latence du premier appel compte plus que la découverte

Auto n'est pas toujours le choix le plus économique. Si vous savez déjà qu'une cible fonctionne avec Single et unblocker activé, appeler Single directement évite le probe et coûte 2 crédits. Auto sur la même cible coûte ce que son échelle dépense.

Quand combiner les approches

Certains flux de travail bénéficient de l'utilisation de plusieurs endpoints :

  1. Découvrir avec auto : transmettez une règle validate et laissez l'échelle déterminer l'échelon dont le site a besoin.
  2. Rejouer avec single : prenez le session.proxy, session.cookies et session.userAgent retournés par auto, puis appelez Single avec ces éléments pour les pages suivantes sur le même hôte.
  3. Basculer vers browser : si single commence à échouer, passez au rendu browser.
  4. Ajouter proxy : si vous êtes bloqué (403 ou page de vérification) sans auto, encapsulez votre requête dans l'endpoint proxy pour une rotation automatique.

Cette approche progressive maintient les coûts au plus bas tout en garantissant un taux de réussite élevé.

Conseils de performance

  • Transmettez une sous-chaîne validate.data.accept sur les cibles protégées. Auto reconnaît les pages de challenge courantes par lui-même, mais seule votre règle peut intercepter une page de vérification inconnue ou une page chargée sans le contenu requis.
  • Utilisez l'endpoint single par défaut pour les hôtes fonctionnels connus et passez au niveau supérieur uniquement si nécessaire.
  • Définissez checkText dans les requêtes browser afin qu'une page rendue sans votre contenu retourne un échec (checkText:<text> not found) au lieu d'un succès. checkText ne force pas FourA à attendre le texte plus longtemps.
  • Définissez maxTries dans les requêtes proxy pour contrôler le comportement de retry (la valeur par défaut est 5, le max est 90).
  • Conservez un timeout_ms raisonnable : 10 à 15 secondes pour la plupart des pages, 30s+ pour les exécutions auto à froid sur des sites protégés.

Étapes suivantes

Mis à jour : 30 septembre 2026