diff --git a/api-playground/sdk-reference-setup.mdx b/api-playground/sdk-reference-setup.mdx
index 6bd4ec7bc..53e1a8115 100644
--- a/api-playground/sdk-reference-setup.mdx
+++ b/api-playground/sdk-reference-setup.mdx
@@ -82,10 +82,11 @@ Add `sdk` to a [group](/organize/navigation#groups) to generate pages inside one
 A group with `sdk` can also list `pages` that you write yourself. Your pages appear first, followed by the generated reference groups.
 
 <Note>
-  You can declare `sdk` on a [tab](/organize/navigation#tabs) or a [group](/organize/navigation#groups).
+  You can declare `sdk` on a [tab](/organize/navigation#tabs), a [group](/organize/navigation#groups), or a [version](/organize/navigation#versions).
 
   - A tab with `sdk` can include `groups`, but no other navigation structures, such as `pages`, `versions`, or `languages`. It also cannot include an `openapi`, `asyncapi`, or `graphql` property.
   - A group with `sdk` can include `pages` and nested groups, but cannot include a `graphql` property.
+  - A version with `sdk` generates pages scoped to that version. See [Version your SDK reference](#version-your-sdk-reference).
 </Note>
 
 <ParamField path="format" type="string" required>
@@ -97,7 +98,7 @@ A group with `sdk` can also list `pages` that you write yourself. Your pages app
 </ParamField>
 
 <ParamField path="directory" type="string">
-  The URL path prefix for generated pages. Defaults to `sdk-reference`.
+  The URL path prefix for generated pages. Defaults to `sdk-reference`, or `sdk-reference/<version>` when declared on a version.
 </ParamField>
 
 Add multiple tabs or groups to document multiple libraries. For example, use two groups in the same tab for the stable and beta versions of an SDK. Use a unique `directory` for each library to avoid route collisions.
@@ -106,6 +107,33 @@ Add multiple tabs or groups to document multiple libraries. For example, use two
   Add your artifact directory to [`.mintignore`](/organize/mintignore) so Mintlify treats artifacts as build inputs rather than publishing them as static assets.
 </Tip>
 
+## Version your SDK reference
+
+Declare `sdk` on a version node in `navigation.versions` to generate a separate reference for each version of your SDK. Point each version's `source` at the artifact for that release.
+
+```json
+"navigation": {
+  "versions": [
+    {
+      "version": "v2",
+      "sdk": {
+        "format": "typedoc",
+        "source": "sdk-artifacts/typedoc-v2.json"
+      }
+    },
+    {
+      "version": "v1",
+      "sdk": {
+        "format": "typedoc",
+        "source": "sdk-artifacts/typedoc-v1.json"
+      }
+    }
+  ]
+}
+```
+
+When you omit `directory` on a version, generated pages default to `sdk-reference/<version>`, so versions do not collide. If you set `directory` explicitly, use a unique value for each version. Duplicate directories cause route collisions that fail the build.
+
 ## Generated pages
 
 Mintlify adds the generated navigation groups after any `groups` on the tab. If you add `sdk` to a group, the generated groups appear after that group's `pages`. The groups vary by format and may represent modules, packages, namespaces, or symbol types.
@@ -199,9 +227,8 @@ docs-repo/
 When the SDK is in its own repository, you have two options.
 
 1. **Commit the artifact to your documentation repository.** In the SDK repository, run a CI job at release time. The job generates the artifact and opens a pull request or pushes a commit with the updated file to your documentation repository. Merge the change into your deployment branch to trigger a site deployment. Point `source` at the committed path, as in the single-repository setup.
-
 2. **Host the artifact and fetch it at build time.** Upload the artifact to a stable HTTPS URL. For example, an S3 bucket, GitHub Releases asset, or Maven Central for Javadoc jars. Set `source` to the URL. Trigger a documentation site deployment to fetch the new artifact whenever you update it. Call the [Trigger deployment](/api/update/trigger) endpoint from your SDK release pipeline after you publish the artifact.
 
 <Tip>
   If your release cadence is low or you want the documentation repository to be the source of truth, commit the artifact to your documentation repository. If your releases are frequent, artifacts are large, or you already publish them (for example, Javadoc jars on Maven Central), host the artifact and fetch it at build time.
-</Tip>
+</Tip>
\ No newline at end of file