Lire des pages web dans les agents IA n8n avec WebReaderAPI

Pourquoi utiliser le node HTTP Request comme outil ?

Parce qu'il fait déjà tout ce dont cette API a besoin : une requête GET, un header et deux paramètres de requête. n8n documente que le node HTTP Request peut s'exécuter comme node classique ou être attaché à un agent IA comme outil, et que certaines options n'existent que dans la forme outil.

Il n'y a rien de notre côté à installer ou à mettre à jour, et la clé réside dans le credential store de n8n plutôt que dans le workflow. Donnez à n8n sa propre clé, afin que son usage soit visible séparément de vos autres scripts et que vous puissiez la révoquer seule. Créez plusieurs clés API, par exemple une par agent ou par projet, et révoquez n'importe laquelle depuis votre dashboard.

Comment le modèle choisit-il l'URL à lire ?

Laissez le modèle définir le paramètre url. n8n affiche un bouton à côté des champs de paramètre éligibles qui confie la valeur au modèle, et vous pouvez aussi écrire l'expression vous-même avec la fonction $fromAI() de n8n. Elle prend une clé, une description, un type et une valeur par défaut facultative, par exemple la clé url, la description "The http or https address of the page to read" et le type string.

n8n documente que $fromAI() ne fonctionne que dans les outils connectés au node AI Agent. Rédigez aussi la description de l'outil en mots simples, comme "Reads a public web page and returns its main content as Markdown", pour que l'agent sache quand l'appeler.

Pourquoi activer Optimize Response ?

Parce que tout ce que renvoie un outil entre dans le contexte du modèle. Optimize Response est une option réservée aux outils qui réduit les données transmises au modèle. Avec le type de réponse JSON, vous pouvez n'inclure que les champs sélectionnés ; gardez title, final_url et markdown et abandonnez le reste.

Limitez la longueur de notre côté avec max_chars, qui coupe le Markdown avant qu'il ne quitte l'API. Les types de réponse HTML et Text du node ont leur propre option Truncate Response, mais avec notre réponse JSON, max_chars est le contrôle le plus simple.

Comment utiliser l'API dans un workflow planifié ?

Utilisez le node HTTP Request comme node classique, pas comme outil, derrière un Schedule Trigger. Donnez-lui un url fixe, par exemple un changelog ou une page de tarifs que vous suivez, et envoyez le champ markdown au node suivant : un fichier, une base de données, un message de chat ou une comparaison avec l'exécution précédente.

Chaque exécution lit une page par URL. Surveiller 20 pages une fois par jour consomme environ 600 crédits par mois pour les pages sans navigateur, donc 10 000 pages (3,75 $US) dure plus d'un an. Les crédits prépayés n'expirent jamais : les pages non utilisées restent sur votre compte jusqu'à ce que vous les utilisiez.

Que se passe-t-il quand un site refuse la lecture ?

Le node reçoit une réponse d'erreur avec un code comme blocked_by_robots ou target_refused, et rien n'est facturé. Nous respectons robots.txt : notre crawler s'identifie comme WebReaderAPI, suit les règles écrites pour lui ou pour tous les robots, et ne lit pas une page qu'un site interdit. Les pages refusées ne sont pas facturées. Dans un agent, laissez l'outil renvoyer l'erreur pour que le modèle puisse l'expliquer ou essayer une autre source ; dans un workflow planifié, acheminez les erreurs vers une branche qui les journalise. La page errors liste tous les codes.

Puis-je tester l'appel avant de construire le workflow ?

Exécutez le même appel dans un terminal avec curl, comme montré dans les recettes curl. S'il fonctionne là-bas et échoue dans n8n, la cause est dans les réglages du node, le plus souvent la valeur de la credential sans le préfixe Bearer ou le paramètre url laissé vide.