[Project name]

[One or two sentences that summarise the project for a language model: what it is, who it is for, and the key facts needed to understand the rest of this file. Example: "Acme Pay is a REST API and SDK for accepting card and bank payments in 30 countries. All amounts are integers in minor currency units, and every write request accepts an Idempotency-Key header."]

[Optional details in plain paragraphs or bullet lists, without headings. Use this space for the facts a model most needs before following links: key concepts, naming conventions, and common pitfalls.]

• [Product name] has two interfaces: the REST API at https://api.example.com/v1 and official SDKs for [TypeScript, Python, Go].
• Authentication uses secret keys sent as Authorization: Bearer sk_...; test keys start with sk_test_.
• Prefer the SDKs over raw HTTP in code examples.

Docs

• Quickstart: Install the SDK and make a first test payment in five minutes
• Authentication: API keys, scopes and key rotation
• Payments guide: Creating, capturing and refunding payments
• Webhooks: Event types, signature verification and retries
• Errors: Error format, codes and how to handle each

API reference

• REST API reference: Every endpoint with parameters and examples
• OpenAPI document: Machine-readable API description
• TypeScript SDK: Installation, configuration and method list

Examples

• Checkout integration: Complete server and client example
• Subscription billing: Recurring payments with trials

Optional

• Changelog: Release history and breaking changes
• Architecture overview: Background reading on how the platform is built
• Glossary: Payment industry terms used in the docs

About this file

This section explains the format and should be removed before publishing.

Structure. The proposal defines a fixed order. The H1 with the project name is the only required element. A blockquote with a short summary follows, then any number of paragraphs or lists without headings, then zero or more H2 sections. Each H2 section is a Markdown list where every item is a link, optionally followed by a colon and a short note: - [Name](url): notes.

The Optional section. A section titled exactly Optional marks links that a tool can skip when it needs a shorter context. Put secondary material there, such as changelogs or background reading.

Where to host it. Serve the file at /llms.txt on the site root, with a text or Markdown content type. The proposal also suggests offering a Markdown version of each HTML page at the same URL with .md appended, so that tools can fetch clean text instead of parsing HTML.

llms-full.txt. Many sites also publish /llms-full.txt, a single file that contains the full text of the linked documentation concatenated in Markdown. It suits tools that want everything in one request. Generate it from your docs build so it never drifts from the source pages, and keep /llms.txt as the short, curated index.

Maintenance. Regenerate both files when documentation changes, check that every link resolves, and keep notes to one line each.

Standard and licence note

Based on the llms.txt proposal published at llmstxt.org (H1 name, blockquote summary, optional details, H2 link-list sections and an Optional section). Original text written for this collection; example URLs are placeholders. Template licence: MIT.