llms.txt

The wrapper publishes a /llms.txt — a single, deep, plain-text guide to the entire API, written for machines to read.

Open /llms.txt

What llms.txt is

llms.txt is a small convention: a project serves one Markdown file at a well-known root path (/llms.txt) that an LLM or coding agent can fetch to understand the project in one request, instead of crawling and guessing across a docs site. It is the machine-facing counterpart to a human “getting started” page — same intent, one file, no navigation.

Who it is for

It is for LLM tools and coding agents pointed at this API — a copilot writing an integration, an agent generating client code, or any assistant that needs the whole contract in context. A human can read it, but the human docs you are reading now (concepts, guides, this reference) are the friendlier path; /llms.txt exists so a model does not have to reconstruct the API surface from scattered pages.

Where it lives

It is served at the site root, /llms.txt — deliberately above the /api/v1 prefix, because the llms.txt convention expects the file at the domain root. It is returned as text/plain so browsers and crawlers render it inline.

Point your tool at it directly: /llms.txt.

What is in it

/llms.txt is a superset of this reference’s map, kept in sync with the code. In one fetch it covers:

• Platform & conventions — the base URL, versioning, auth header, the 404-over-403 existence rule, one-time secrets, and rate-limit headers.
• Authentication axes — the actor-type model (project, integration, user, space) and how each credential is resolved. See Authorization axes.
• Scopes & enforcement — the scope vocabulary and the SCOPE_ENFORCEMENT modes.
• Rate limiting — the layered hierarchy and its response headers. See Admin settings.
• Error codes — the shared error envelope and its codes.
• Every endpoint group — health, auth and two-factor, admin (projects, stats, settings), plans, users, files (including folder browsing), images, jobs, stats, audit, keys and integrations, user tokens, and spaces (“Rutas”).
• The async image pipeline — upload → 202 { job_id } → poll. See the image compression guide.
• Audit & multi-tenancy — the immutable log and the per-tenant storage layout.
• Environment — the consumer-relevant configuration.

Because it is generated from the same source of truth as the live API reference, it stays current with the running stack — treat it as the canonical, agent-ready snapshot of the surface.