.md-jumeau de chaque page
Section intitulée « .md-jumeau de chaque page »Chaque page de documentation a un jumeau Markdown brut au même chemin avec le suffixe .md. Ouvrez /agent-setup - il y a aussi /agent-setup.md, le même texte sans l’enveloppe HTML, les imports MDX sont supprimés, servi comme text/markdown.
Cela alimente deux actions dans le menu de la page : Copy as Markdown (place le texte brut dans le presse-papiers pour l’insérer dans un chat avec un modèle) et View as Markdown (ouvre directement la version .md). L’agent n’a pas besoin d’analyser le DOM - il prend le texte prêt à l’emploi.
Menu déroulant d’actions en haut de la page
Section intitulée « Menu déroulant d’actions en haut de la page »Dans le coin supérieur droit de chaque page, il y a un menu d’actions conçu spécifiquement pour le workflow des agents :
- Copy as Markdown - texte brut de la page dans le presse-papiers
- View as Markdown - ouvrir le jumeau
.md - Open in ChatGPT - envoyer la page dans ChatGPT en un seul clic
- Open in Claude - la même chose pour Claude
- Connect MCP - accéder à la configuration du serveur MCP
Au lieu de “copiez l’URL, ouvrez le chat, demandez d’aller sur la page” - une seule action.
llms.txt et llms-full.txt
Section intitulée « llms.txt et llms-full.txt »Selon le standard llmstxt.org, nous fournissons deux fichiers :
/llms.txt- index de toutes les pages de documentation, regroupé par sections (API Reference, Use Cases, Examples, Products). Une carte pour l’agent, pour savoir par où commencer./llms-full.txt- toute la documentation dans un seul fichier texte brut. Pour l’indexation hors ligne dans une base de vecteurs ou pour une insertion unique dans le contexte du modèle.
Si vous construisez un RAG sur notre API, llms-full.txt est un corpus prêt à l’emploi, pas besoin de crawler le site.
Spécifications lisibles par machine
Section intitulée « Spécifications lisibles par machine »Le contrat est fourni dans plusieurs formats pour différents outils :
/v1/openapi.json- spécification OpenAPI 3.1 canonique avec des exemples et des échantillons de code. Pour la génération de code client et tout outil OpenAPI.- Alias Swagger -
/v1/swagger.json,/v1/v3/api-docset d’autres redirigent vers la canonique pour que les outils qui recherchent les chemins habituels ne trébuchent pas. - Collection Postman -
/postman/astroway-api.jsonpour l’importation dans Postman en un seul clic.
/agent-setup pour des clients spécifiques
Section intitulée « /agent-setup pour des clients spécifiques »La page /agent-setup/ - n’est pas un guide général, mais des instructions séparées pour sept clients : Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Cline, Codex. Chacune fournit une configuration exacte et un exemple curl tools/list pour vérifier la connexion avant d’écrire du code.
Essai intégré
Section intitulée « Essai intégré »Sur les pages de référence API, chaque opération a un widget intégré try-it : vous insérez une clé sandbox, vous modifiez le corps de la requête, vous appuyez sur “Send” - et vous voyez la réponse réelle sans quitter la documentation. La méthode, le chemin et l’exemple de corps sont pris à partir de l’extrait curl déjà généré, donc le widget ne fait pas de requêtes supplémentaires sur openapi.json.
Pourquoi tout cela
Section intitulée « Pourquoi tout cela »Une thèse simple : si votre produit est une API, la documentation doit être non seulement lisible par les humains, mais aussi consommable par des agents. La moitié des intégrations aujourd’hui commencent par un développeur qui lance un lien vers la documentation dans Claude ou Cursor et demande “connecte ça”. Nous avons fait en sorte qu’à l’autre bout, il y ait du texte brut et un contrat machine, pas du HTML qui doit être analysé.
Essayez par vous-même : ouvrez n’importe quelle page de documentation, cliquez sur le menu d’actions en haut à droite - et vous verrez “Open in Claude”.
Le même Swiss Ephemeris que Solar Fire - en 4 lignes de code.
Clé gratuite sans carte. 5 000 appels par mois avant le premier paiement.