- [ 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 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) ## 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. A compatible agent or retrieval workflow can be configured to use llms.txt as its API reading list. In that controlled case, you can trace which documents were loaded before an answer. ## 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. Note 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://docs.stripe.com/llms.txt) - [ Anthropic docs llms.txt ](https://platform.claude.com/llms.txt)