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 with an AI integration entry link and links to the two corpora below. It does not list every page.
https://docs.sudomimus.com/llms-full.txt	Full corpus — every English documentation page concatenated into one file.
https://docs.sudomimus.com/llms-small.txt	Small corpus — an alternative generated representation of the English documentation; it is not a curated summary.

The full and small 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.

Choosing the amount of context

The current llms-full.txt and llms-small.txt outputs contain the same substantive English content, including detailed rule tables and edge-case guidance. Their byte sizes differ, but small does not provide a substantial reduction in subject matter. Do not infer token counts or a fixed size ratio from the filenames.

For an integration task, start with the AI integration entry or the relevant flow page. Read its Markdown and follow only the links needed for the task. Use an aggregate corpus when the assistant needs broad context across integration paths and has enough capacity. Check the current output size against your model’s context budget; integration still requires configuration and validation.

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, /direct-issue/public-key).
• Device API — the public-client device authorization endpoints (/device-authorize, /device-token).

These pages are authoritative for exact paths, parameters, request bodies, and status codes. Provide the relevant pages to an assistant when generating strongly typed client code.

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.