Enad docs are versioned by track, not by the whole website. A React SDK page, TypeScript SDK page, Search page, API page, event page, and agent guide can each point at a different package version, API contract, schema, catalog, or output.

There is no single global docs version number. Always check the page track and version before copying code or treating a page as contract truth.

What a track is

A track is the thing a page describes. Common tracks include:

• An SDK package, such as the React SDK or TypeScript SDK.
• An API, such as Management, Shopper, Auth, or DAM.
• A Search GraphQL schema or operation surface.
• An event catalog or event-family surface.
• A reference surface.
• An agent file, such as llms.txt or the manifest.

A page can be useful guidance even when exact fields or payloads live in a deeper reference page. The page intro should tell you which route to open next.

Package tracks

Package docs follow package releases. Use package-track pages when your question is about SDK installation, exports, generated types, components, hooks, providers, or runtime behavior.

Start with the React SDK, React SDK setup, or TypeScript SDK route before opening lower-level package reference pages.

• React SDK latest
• React SDK setup
• TypeScript SDK latest

Package-track rules:

• latest means the current recommended docs route for new work on that package.
• Pinned package routes should match a package minor line when archived routes exist.
• A minor route normally describes the latest patch in that minor line unless a patch-specific note says otherwise.
• Exact exports, component props, method signatures, generated types, and package runtime behavior stay in the package reference for that track.

API tracks

API docs follow the API or API contract they describe. Start at APIs when choosing between Management, Shopper, Auth, DAM, Integrations, Search, and Media.

Start with the API, Reference, Media, Events, or Search route that matches the job before opening exact contract files.

• APIs
• Reference
• Media
• Events
• Search latest

API-track rules:

• If a public API version or spec revision exists, the docs should name it.
• If no separate public version is exposed, the docs may use latest or current.
• OpenAPI-backed routes and reference pages own endpoint, parameter, request-body, response, auth, and schema details.
• Event pages should defer to the event catalog when exact event names and payloads matter.

Exact reference files

Exact reference files are the safest place to verify contract facts. Examples include package reference data, OpenAPI specs, Search GraphQL schema and operation files, endpoint reference pages, agent manifests, and event catalogs when available.

Use reference files when you need to answer questions like:

• Which export, prop, hook, helper, method, or generated type exists?
• Which endpoint path, parameter, request field, or response field is valid?
• Which Search operation, fragment, variable, or document shape exists?
• Which event name or payload shape is canonical?
• Which docs routes are safe for an agent to read or quote?

Authored docs explain how to use those facts. They should not silently replace them.

Guidance-only pages

Some pages are guidance-only. That does not mean the route is useless. It means the page helps with routing, context, and decisions while exact reference details live in a package, OpenAPI, Search, event, or endpoint reference.

When a page is guidance-only, use it for route selection and context. Keep exact facts in the reference surface that owns them.

• Do not treat example fields or inferred behavior as contract truth.
• Verify exact facts in the package, OpenAPI, Search, event, or endpoint reference.
• Expect the page to link you to the more exact reference when precision matters.

Agent files and llms outputs

Agent files are part of the versioning model, but they are routing and guidance surfaces rather than replacements for SDK/API reference pages.

Use:

• Agent guides for the human entry point
• /llms.txt for the short agent index
• /llms-full.txt for the larger agent bundle
• /ai/manifest.json for structured route data and copy guidance

Agent files should help agents choose the right route. If an agent needs exact package exports, API schema details, Search operations, or event payloads, route it to the exact package/API/Search/event reference.

Choose the right route

For new work, start with the latest route for the package or API track.

For an existing app, use the route that matches the installed package minor or API contract when a pinned route exists.

For a copied snippet, check the page track first, then verify the package, API, Search, or event reference.

For agent help, start with Agent guides, /llms.txt, and /ai/manifest.json. Add the exact reference when package exports, schemas, operations, or payloads matter.

For behavior comparisons, use pinned package or API routes. When route pins are not available, compare reference files from each revision.

Safe rule of thumb

If a fact can break production when wrong, verify it in the exact reference:

1. Package/component behavior: package reference.
2. REST API behavior: OpenAPI and endpoint reference pages.
3. Search behavior: Search schema, operation documents, and package reference.
4. Event behavior: event catalogs.
5. Agent routing: llms outputs and the agent manifest.
6. Human workflow guidance: authored guide pages.

Start with Start when you need route selection, and use Troubleshooting when a docs path or first-run setup is unclear.