AstroWay/api v2.325.2 · es
todos los sistemas funcionando con normalidad

Documentación hecha para agentes de IA, no solo para personas

La documentación clásica está hecha para ojos humanos: HTML cuidado, resaltado de código, navegación. Pero hoy la mitad del tráfico a la documentación son agentes y asistentes, que necesitan texto plano y no el renderizado. Repasamos lo que hemos añadido: un gemelo .md de cada página, llms.txt, especificaciones legibles por máquinas, un desplegable "abrir en ChatGPT / Claude" y try-it inline.

La documentación clásica está hecha para personas: HTML renderizado, resaltado de sintaxis, barra lateral, búsqueda. Pero cada vez más a menudo quien recorre la documentación no es una persona, sino un agente (Claude, Cursor, ChatGPT), y a él todo ese renderizado solo le estorba. Necesita texto limpio y un contrato legible por máquinas.

Hemos hecho que la documentación sirva para ambos. Esto es lo que hay debajo.

Cada página de la documentación de contenido tiene un gemelo en Markdown en bruto en la misma ruta con el sufijo .md. Si abres /agent-setup, también existe /agent-setup.md: el mismo texto sin el envoltorio HTML, con los imports de MDX eliminados, servido como text/markdown.

Esto alimenta dos acciones del menú de la página: Copy as Markdown (copia el texto limpio al portapapeles para pegarlo en un chat con el modelo) y View as Markdown (abre directamente la versión .md). El agente no necesita parsear el DOM: se lleva el texto ya listo.

Desplegable de acciones en la parte superior de la página

Sección titulada «Desplegable de acciones en la parte superior de la página»

En la esquina superior derecha de cada página hay un menú de acciones pensado precisamente para el flujo de trabajo con agentes:

  • Copy as Markdown: el texto limpio de la página al portapapeles
  • View as Markdown: abrir el gemelo .md
  • Open in ChatGPT: pasar la página a ChatGPT con un clic
  • Open in Claude: lo mismo para Claude
  • Connect MCP: ir a la configuración del servidor MCP

En lugar de “copia la URL, abre el chat, pide que entre en la página”, una sola acción.

Siguiendo el estándar de llmstxt.org servimos dos archivos:

  • /llms.txt: un índice de todas las páginas de la documentación, agrupado en secciones (API Reference, Use Cases, Examples, Products). El mapa que le dice al agente por dónde empezar.
  • /llms-full.txt: toda la documentación en un único archivo de texto plano. Para indexarla offline en una base vectorial o para pegarla de una vez en el contexto del modelo.

Si construyes un RAG sobre nuestra API, llms-full.txt es un corpus ya preparado: no hace falta rastrear el sitio.

El contrato se sirve en varios formatos para distintas herramientas:

  • /v1/openapi.json: la especificación canónica OpenAPI 3.1 con ejemplos y code samples. Para generar clientes y para cualquier herramienta de OpenAPI.
  • Alias de Swagger: /v1/swagger.json, /v1/v3/api-docs y otros redirigen con 301 al canónico, para que las herramientas que buscan las rutas habituales no tropiecen.
  • Colección de Postman: /postman/astroway-api.json para importarla en Postman con un clic.

La página /agent-setup/ no es una guía general, sino instrucciones separadas para siete clientes: Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Cline y Codex. Cada una da la configuración exacta y un ejemplo curl de tools/list para comprobar la conexión antes de escribir código.

En las páginas de la referencia de la API, cada operación tiene un widget try-it integrado: pegas una clave sandbox, editas el cuerpo de la petición, pulsas “Send” y ves la respuesta real sin salir de la documentación. El método, la ruta y el cuerpo de ejemplo se toman del snippet curl ya generado, así que el widget no hace peticiones de más a openapi.json.

La tesis es simple: si tu producto es una API, la documentación tiene que servir no solo para leerla con los ojos, sino también para que la consuma un agente. Hoy la mitad de las integraciones empiezan cuando un desarrollador le pasa el enlace de la documentación a Claude o a Cursor y le pide “conecta esto”. Nos hemos asegurado de que al otro lado haya texto limpio y un contrato para máquinas, no HTML que haya que parsear.

Pruébalo tú mismo: abre cualquier página de la documentación, pulsa el menú de acciones arriba a la derecha y verás “Open in Claude”.

MakSeong · AstroWay

Construyo AstroWay API: envuelvo cálculos astrológicos al segundo de arco en un REST puro y escribo sobre los detalles aburridos que realmente importan.

// construye sobre esto

Posiciones al segundo de arco en 4 líneas de código.

Clave gratuita sin tarjeta. 5 000 llamadas al mes antes del primer pago.

Más del blog ver todas las publicaciones →

Engineering 2026-07-15

Tres SDK oficiales: TypeScript, Python, PHP en lugar de curl sin procesar

El HTTP crudo funciona, pero un cliente tipado ahorra horas: autocompletado de rutas, tipos de solicitud y respuesta, reintento incorporado en 408/409/429/5xx y jerarquía de errores estilo Stainless. Analizamos los tres SDK oficiales - @astroway/sdk (npm), astroway (PyPI), astroway/sdk (Packagist) - y cómo se generaron a partir de un único contrato OpenAPI.

Industry 2026-06-05

Free Astrology API: Which One Has the Best Free Tier in 2026?

A side-by-side of free tiers across the major astrology APIs - credits, request caps, card requirements - and how much you can actually build for free.

Engineering 2026-06-05

Horoscope API Tutorial: Build a Daily Horoscope Feature

Add daily, weekly and monthly horoscopes to your app via API - sign-based text vs transit-based personalization - with TypeScript and Python code.