- [ Home ](/) / - [ Blog ](/blog/) / - llms.txt for API products # llms.txt for API-first products Developers constantly ask AI assistants for help with APIs. A well-curated llms.txt reduces hallucinated endpoints, wrong parameters, and outdated examples. Last updated: April 22, 2026 ## Why API products benefit most API-first products and developer tools are among the best-positioned site types to benefit from llms.txt. Developers regularly ask AI coding assistants for help with APIs: how to paginate, what the rate limits are, how to authenticate, how to handle a specific error. These are precise, answerable questions. When the AI has accurate documentation, the answers are useful. When it does not, it approximates, and API approximations cause bugs. Agent frameworks like Cursor and Windsurf explicitly fetch llms.txt when a developer adds a library or documentation source to their session context. Your llms.txt directly determines what the AI knows about your API when helping a developer use it. ## The API hallucination problem AI language models sometimes generate plausible-but-incorrect API details. Common patterns: - Endpoints that do not exist or have been renamed. - Parameters from a previous API version. - Response schema fields that are outdated or wrong. - Authentication methods that your API does not support. - Rate limits from a different tier or an old pricing model. These errors happen because the model's training data is months or years old, and APIs evolve. When a retrieval system fetches your actual documentation before answering, it uses your current content. llms.txt helps by pointing the retrieval system to your authoritative pages. ℹ llms-full.txt for API reference If your API reference is very large or changes frequently, consider also publishing llms-full.txt with full page content inlined. ## What to include For API-first products, prioritize these page types: - **API reference**, complete endpoint reference. If very long, link the top-level page. - **Authentication guide**, how to obtain credentials and pass them in requests. - **Quickstart guide**, the fastest path from zero to a working API call. - **Rate limits and quotas**, specific limits by tier and endpoint type. - **Error reference**, error codes and their meanings. - **SDK documentation links**, one link per officially supported language SDK. - **Changelog or release notes**, helps retrieval systems understand the current API state. - **Webhooks reference**, if your API sends webhooks, link it. ## What to exclude - **Auth-gated documentation**, pages behind login will fail when fetched by AI agents. - **Internal or beta pages**, do not link pages not ready for public consumption. - **Deprecated API versions**, exclude old version docs. - **Marketing landing pages**, not useful for developers asking technical questions. - **Community forum or Slack links**, dynamic content AI crawlers cannot reliably parse. ## Example template A full example for a hypothetical API product. Adapt to your documentation structure. ``` # Acme API > Acme provides a REST API for real-time inventory management. The API supports CRUD > operations on products, locations, and stock adjustments, plus webhook notifications. > Authentication uses API keys in the Authorization header. ## Core documentation - [API reference](https://docs.acme.example/api/): complete endpoint reference. - [Authentication](https://docs.acme.example/authentication/): API key setup and OAuth 2.0. - [Quickstart](https://docs.acme.example/quickstart/): first API call in five minutes. - [Rate limits](https://docs.acme.example/rate-limits/): limits by tier. - [Errors](https://docs.acme.example/errors/): error codes and recommended handling. - [Webhooks](https://docs.acme.example/webhooks/): event types and payload schema. ## SDKs - [Python SDK](https://docs.acme.example/sdk/python/): official Python library. - [Node.js SDK](https://docs.acme.example/sdk/node/): official Node.js library. - [Go SDK](https://docs.acme.example/sdk/go/): official Go client. ## Optional - [Changelog](https://docs.acme.example/changelog/): API version history and breaking changes. - [Migration guides](https://docs.acme.example/migrations/): upgrading between major versions. - [Status page](https://status.acme.example/): API uptime and incident history. ``` ## SDK and multi-language considerations If your product has SDKs for multiple languages, link each SDK's documentation separately. Organize them in a clear `## SDKs` section and link the top-level page for each SDK rather than every individual sub-page. ## Keeping it fresh - Add llms.txt review to your API release checklist. - When you release a new major API version, update links to point to current version docs. - When you deprecate documentation pages, remove or replace those links immediately. - Consider auto-generating llms.txt from your documentation CMS if your docs update frequently. ## Continue reading - [llms.txt for documentation sites](/blog/llms-txt-documentation-sites/), broader guide for all docs site types. - [llms-full.txt guide](/llms-full-txt/), inlining full content for retrieval systems. - [Real examples](/examples/), see Stripe and Anthropic's llms.txt files. - [Generator](/generator/), build your file from a form. ## Sources - [ llmstxt.org ](https://llmstxt.org/) - [ Stripe llms.txt ](https://stripe.com/docs/llms.txt) - [ Anthropic docs llms.txt ](https://docs.anthropic.com/llms.txt) On this page - [ Why API products benefit most ](#why-apis) - [ The API hallucination problem ](#hallucination-problem) - [ What to include ](#what-to-include) - [ What to exclude ](#what-to-exclude) - [ Example template ](#example-template) - [ SDK and multi-language considerations ](#sdk-considerations) - [ Keeping it fresh ](#maintenance)