Passer au contenu principal
POST https://api.acedata.cloud/webextrator/render L’API de rendu web WebExtrator est un service de rendu de pages web basé sur Chromium sans interface graphique. Fournissez une URL, et elle renvoie le HTML entièrement rendu (y compris le contenu injecté par JS), le texte brut, le titre de la page et l’URL finale. Render est l’interface la plus bas niveau de WebExtrator. Si vous avez besoin de résultats d’extraction structurés (corps d’article, prix de produits, ingrédients de recettes …), utilisez /webextrator/extract —— il exécute une chaîne complète d’extraction typée sur la même base de rendu.

Processus de demande

Pour utiliser la page de service WebExtrator, rendez-vous d’abord sur la console Ace Data Cloud pour obtenir votre API Token, et conservez-le pour une utilisation ultérieure. Si vous n’êtes pas encore connecté ou inscrit, vous serez automatiquement redirigé vers la page de connexion pour vous inviter à vous inscrire et à vous connecter ; une fois terminé, vous reviendrez automatiquement à la page actuelle. Un seul API Token permet d’appeler tous les services de la plateforme, il n’est pas nécessaire d’en demander un séparément pour chaque service. La première demande offre un quota gratuit, vous permettant d’essayer gratuitement ; lorsque le quota est insuffisant, vous pouvez recharger votre solde commun dans la console.
📘 Documentation complète : Page de service WebExtrator →

Authentification

Toutes les interfaces WebExtrator utilisent l’authentification standard Bearer Token :

Paramètres de requête

Le contrat de la plateforme utilise uniformément snake_case. Le service de rendu interne prend en charge camelCase, mais les appels externes utilisent systématiquement snake_case.

Structure des cookies

Réponse synchrone

Réponse asynchrone

Lorsque async=true (ou callback_url est fourni), renvoie immédiatement (HTTP 200) :
Le résultat sera envoyé via POST à callback_url (s’il est configuré), ou pourra être interrogé activement via /webextrator/tasks.

Structure du rappel

La plateforme effectue un POST de l’enveloppe exactement identique au mode synchrone vers callback_url, avec Content-Type: application/json. Tout retour 2xx est considéré comme confirmé ; les 5xx seront réessayés avec une temporisation exponentielle pendant environ 5 minutes.

Réponse d’erreur

Structure d’erreur :

Exemples

cURL

Python (requests)

Node.js (fetch)

Asynchrone + rappel

Renvoie immédiatement { "success": true, "task_id": "...", "trace_id": "...", "started_at": 1777717800.123 } ; lorsque la tâche est terminée, la plateforme envoie le résultat complet par POST à votre callback_url.

Forcer le contournement du cache

Conseils et pièges

  • Il est très important de bien choisir wait_until. networkidle est le plus fiable mais le plus lent ; domcontentloaded est rapide mais peut manquer du contenu injecté de manière asynchrone ; load convient aux pages statiques traditionnelles.
  • La clé de cache ignore async. Les requêtes synchrones et asynchrones pour la même URL atteignent la même entrée de cache, les basculer librement ne l’invalide pas.
  • La clé de cache ignore bypass_cache et cache_ttl_seconds. Ces deux éléments sont des commutateurs d’opération, ils n’affectent pas le contenu de la réponse.
  • cookies et headers segmentent le cache. Personnaliser ces deux éléments fera échouer le premier accès pour la même combinaison.
  • Les SPA lourdes dépassent souvent les 30 secondes par défaut. Il est recommandé d’utiliser timeout: 60, wait_until: "domcontentloaded", delay: 4, puis de combiner avec wait_for_selector pour attendre les éléments qui vous intéressent réellement.
  • block_resources est le moyen le plus rapide de réduire la latence. Les images / polices / médias sont déjà bloqués par défaut ; si votre extraction ne dépend pas de la mise en page CSS, ajouter stylesheet peut encore accélérer.