What to feed your AI

Sudomimus exposes its documentation in several machine-readable forms. Which one you hand your assistant depends on how much context window you can spare and whether you want prose or a formal API contract.

The llms.txt endpoints

Three plain-text endpoints follow the llmstxt.org convention:

URL	What it is
https://docs.sudomimus.com/llms.txt	Index — a short manifest linking to the two corpora below. Good for assistants that fetch pages selectively rather than all at once.
https://docs.sudomimus.com/llms-full.txt	Full corpus — every English documentation page concatenated into one file.
https://docs.sudomimus.com/llms-small.txt	Abridged corpus — the same English documentation with the heaviest reference material trimmed out.

The aggregate corpora are English-only. To give an assistant a Chinese page, use the .md URL for the matching page under any other language supported by this website.

Abridged or full?

Both corpora cover the same ground — shared platform concepts, the separate Connect/OIDC/native flows, and the three-layer rule model. They differ only in depth:

• llms-full.txt includes everything, including the long per-method and per-payload reference tables (every OAuth provider, every rule method, every edge case). It is roughly three times the size of the abridged version. Use it when your assistant has a large context window and you want a complete, one-shot integration.
• llms-small.txt drops those exhaustive tables and the edge-case asides, keeping the conceptual model and the core flows. Use it when context is tight, or when you want the assistant to grasp the model quickly and you’ll point it at specific pages for the details.

When in doubt, start with llms-full.txt — most modern assistants can hold it comfortably.

Per-page Markdown

Append .md to any documentation page URL to fetch just that page as raw Markdown — for example, /en-us/connect/three-key-model.md. This is the precise way to give an assistant one page rather than the whole corpus.

The OpenAPI reference

For the formal request/response contract of the Sudomimus product APIs, point your assistant at the OpenAPI 3.1 reference, generated directly from the published specifications:

• Connect API — the Inquiry endpoints (/establish, /status-poll, /redeem, /info), each with its own operation page.
• Session API — the ordinary application session endpoints (/refresh, /introspect, /logout, /revoke-all).
• Native API — the direct-issue endpoints for native clients (/direct-issue/steam-ticket, /direct-issue/access-key).
• Device API — the public-client device authorization endpoints (/device-authorize, /device-token).

These pages are the source of truth for exact paths, parameters, request bodies, and status codes — feed them to your assistant when you want strongly-typed client code rather than prose-derived guesses.

OIDC uses its native machine-readable contract instead of a duplicate OpenAPI schema. Give your assistant the issuer https://oidc.sudomimus.com, let its OIDC library read discovery, and include the OIDC integration guide for the supported Sudomimus profile and platform-specific constraints. The OpenID Connect and OAuth standards continue to define the underlying protocol semantics.

Staying current

The llms*.txt endpoints and the OpenAPI reference rebuild every time the documentation does — there is no separate “AI version” that lags behind. If your assistant has cached an older fetch, ask it to re-fetch.