From 0a7b5c780f92f29491a93e1856876241af96edeb Mon Sep 17 00:00:00 2001
From: umair <umair.hussain@ably.com>
Date: Thu, 5 Mar 2026 12:47:36 +0000
Subject: [PATCH 1/3] Move auth docs to /docs/platform/auth and update
 navigation

- Move 8 auth MDX files from /docs/auth/ to /docs/platform/auth/
- Add redirect_from entries for all old /docs/auth/* paths
- Add Authentication section to Platform nav (with nested Token auth)
- Remove Authentication section from Pub/Sub nav
- Update cross-references within auth files to new paths
- Fix relative image paths for new directory depth
---
 src/data/nav/platform.ts                      | 44 +++++++++++++++++++
 src/data/nav/pubsub.ts                        | 44 -------------------
 src/pages/docs/{ => platform}/auth/basic.mdx  |  8 ++--
 .../docs/{ => platform}/auth/capabilities.mdx | 24 +++++-----
 .../auth/identified-clients.mdx               | 14 +++---
 src/pages/docs/{ => platform}/auth/index.mdx  | 33 +++++++-------
 .../docs/{ => platform}/auth/revocation.mdx   |  6 ++-
 .../{ => platform}/auth/token/ably-tokens.mdx | 12 ++---
 .../docs/{ => platform}/auth/token/index.mdx  | 30 +++++++------
 .../docs/{ => platform}/auth/token/jwt.mdx    | 16 ++++---
 10 files changed, 123 insertions(+), 108 deletions(-)
 rename src/pages/docs/{ => platform}/auth/basic.mdx (89%)
 rename src/pages/docs/{ => platform}/auth/capabilities.mdx (92%)
 rename src/pages/docs/{ => platform}/auth/identified-clients.mdx (79%)
 rename src/pages/docs/{ => platform}/auth/index.mdx (70%)
 rename src/pages/docs/{ => platform}/auth/revocation.mdx (97%)
 rename src/pages/docs/{ => platform}/auth/token/ably-tokens.mdx (95%)
 rename src/pages/docs/{ => platform}/auth/token/index.mdx (90%)
 rename src/pages/docs/{ => platform}/auth/token/jwt.mdx (97%)

diff --git a/src/data/nav/platform.ts b/src/data/nav/platform.ts
index 8e1df1417d..bc6f43621b 100644
--- a/src/data/nav/platform.ts
+++ b/src/data/nav/platform.ts
@@ -331,6 +331,50 @@ export default {
         },
       ],
     },
+    {
+      name: 'Authentication',
+      pages: [
+        {
+          name: 'Overview',
+          link: '/docs/platform/auth',
+          index: true,
+        },
+        {
+          name: 'Basic auth',
+          link: '/docs/platform/auth/basic',
+        },
+        {
+          name: 'Token auth',
+          pages: [
+            {
+              name: 'Overview',
+              link: '/docs/platform/auth/token',
+              index: true,
+            },
+            {
+              name: 'JWTs',
+              link: '/docs/platform/auth/token/jwt',
+            },
+            {
+              name: 'Ably Tokens',
+              link: '/docs/platform/auth/token/ably-tokens',
+            },
+          ],
+        },
+        {
+          name: 'Token revocation',
+          link: '/docs/platform/auth/revocation',
+        },
+        {
+          name: 'Identified clients',
+          link: '/docs/platform/auth/identified-clients',
+        },
+        {
+          name: 'Capabilities',
+          link: '/docs/platform/auth/capabilities',
+        },
+      ],
+    },
     {
       name: 'Tools',
       pages: [
diff --git a/src/data/nav/pubsub.ts b/src/data/nav/pubsub.ts
index 30454c9ded..7285937af7 100644
--- a/src/data/nav/pubsub.ts
+++ b/src/data/nav/pubsub.ts
@@ -83,50 +83,6 @@ export default {
         },
       ],
     },
-    {
-      name: 'Authentication',
-      pages: [
-        {
-          name: 'Overview',
-          link: '/docs/auth',
-          index: true,
-        },
-        {
-          name: 'Basic auth',
-          link: '/docs/auth/basic',
-        },
-        {
-          name: 'Token auth',
-          pages: [
-            {
-              name: 'Overview',
-              link: '/docs/auth/token',
-              index: true,
-            },
-            {
-              name: 'JWTs',
-              link: '/docs/auth/token/jwt',
-            },
-            {
-              name: 'Ably Tokens',
-              link: '/docs/auth/token/ably-tokens',
-            },
-          ],
-        },
-        {
-          name: 'Token revocation',
-          link: '/docs/auth/revocation',
-        },
-        {
-          name: 'Identified clients',
-          link: '/docs/auth/identified-clients',
-        },
-        {
-          name: 'Capabilities',
-          link: '/docs/auth/capabilities',
-        },
-      ],
-    },
     {
       name: 'Connections',
       pages: [
diff --git a/src/pages/docs/auth/basic.mdx b/src/pages/docs/platform/auth/basic.mdx
similarity index 89%
rename from src/pages/docs/auth/basic.mdx
rename to src/pages/docs/platform/auth/basic.mdx
index bdcc9a6b02..04b9c4dc8f 100644
--- a/src/pages/docs/auth/basic.mdx
+++ b/src/pages/docs/platform/auth/basic.mdx
@@ -1,9 +1,11 @@
 ---
 title: Basic auth
 meta_description: "Basic authentication allows you to authenticate a secure server using an Ably API key and secret."
+redirect_from:
+  - /docs/auth/basic
 ---
 
-Basic authentication is the simplest way to authenticate with Ably. It requires passing an [API key](/docs/auth#api-key) when instancing an SDK.
+Basic authentication is the simplest way to authenticate with Ably. It requires passing an [API key](/docs/platform/auth#api-key) when instancing an SDK.
 
 <Aside data-type='important'>
 Private API keys should never be shared with untrusted parties, and as such, should only be used by your trusted secure servers when authenticating with Ably.
@@ -115,14 +117,14 @@ $rest = new Ably\AblyRest(['key' => '{{API_KEY}}']);
 
 The process used by Ably SDKs to authenticate with Ably using basic authentication is illustrated in the following diagram:
 
-![Basic authentication process diagram](../../../images/content/diagrams/Ably-API-Auth1.png)
+![Basic authentication process diagram](../../../../images/content/diagrams/Ably-API-Auth1.png)
 
 ## When to use basic auth <a id="when"/>
 
 Ably recommends that basic authentication is only used server-side because of the following potential issues:
 
 * The secret is passed directly by the client to Ably, so it is only permitted for connections that are over TLS, to prevent the key secret being intercepted.
-* All of the configured [capabilities](/docs/auth/capabilities) of the key are implicitly possible in any request, and clients that legitimately obtain this key may then abuse the rights for that key.
+* All of the configured [capabilities](/docs/platform/auth/capabilities) of the key are implicitly possible in any request, and clients that legitimately obtain this key may then abuse the rights for that key.
 * A client that authenticates using an API key can claim any client ID it chooses. Therefore this client ID cannot be trusted to represent the genuine identity of the client. Client IDs should be assigned by the server, once the client's credentials have been authenticated.
 
 <Aside data-type='note'>
diff --git a/src/pages/docs/auth/capabilities.mdx b/src/pages/docs/platform/auth/capabilities.mdx
similarity index 92%
rename from src/pages/docs/auth/capabilities.mdx
rename to src/pages/docs/platform/auth/capabilities.mdx
index 9146e63f69..c1209c04ce 100644
--- a/src/pages/docs/auth/capabilities.mdx
+++ b/src/pages/docs/platform/auth/capabilities.mdx
@@ -1,13 +1,15 @@
 ---
 title: Capabilities
 meta_description: "Capabilities define which operations can be carried out on which channels by a client."
+redirect_from:
+  - /docs/auth/capabilities
 ---
 
 API keys and Ably-compatible tokens, have a set of capabilities assigned to them that specify which operations (such as subscribe or publish) can be performed on which channels.
 
 API keys are long-lived, secret and typically not shared with clients. API key capabilities are configured using the [dashboard](https://ably.com/dashboard), or using the [Control API](/docs/platform/account/control-api).
 
-Ably-compatible tokens are designed to be shared with untrusted clients, are short-lived, and can be configured and issued programmatically. For restricting client access to channels, tokens provide far more flexibility and security than API key capabilities. See [selecting an authentication mechanism](/docs/auth#selecting-auth) to understand why token authentication is the preferred option in most scenarios.
+Ably-compatible tokens are designed to be shared with untrusted clients, are short-lived, and can be configured and issued programmatically. For restricting client access to channels, tokens provide far more flexibility and security than API key capabilities. See [selecting an authentication mechanism](/docs/platform/auth#selecting-auth) to understand why token authentication is the preferred option in most scenarios.
 
 ### Capability changes and existing connections <a id="capability-changes-existing-connections"/>
 
@@ -15,9 +17,9 @@ Ably-compatible tokens are designed to be shared with untrusted clients, are sho
 When you change a key's capabilities in the dashboard, existing connections using that key do **not** receive the updated capabilities immediately. Connections must be closed and re-opened to pick up the new capabilities.
 </Aside>
 
-Once created, it's best to think of keys and tokens as being immutable. To modify the permissions granted to existing connections, the recommended approach is to use [token authentication](/docs/auth/token) and issue the client a new token with the updated permissions you want them to have.
+Once created, it's best to think of keys and tokens as being immutable. To modify the permissions granted to existing connections, the recommended approach is to use [token authentication](/docs/platform/auth/token) and issue the client a new token with the updated permissions you want them to have.
 
-The one exception is if a key is revoked entirely, in which case all connections using that key (or a token derived from that key) will be forcibly terminated. See [token revocation](/docs/auth/revocation) for more information.
+The one exception is if a key is revoked entirely, in which case all connections using that key (or a token derived from that key) will be forcibly terminated. See [token revocation](/docs/platform/auth/revocation) for more information.
 
 ## Resource names and wildcards <a id="wildcards"/>
 
@@ -71,7 +73,7 @@ Ably does not provide numeric limits on channel access. Control channel access u
 
 Channel access is controlled through:
 
-* [Token authentication](/docs/auth/token) to restrict access by issuing tokens with specific capabilities to authorized users.
+* [Token authentication](/docs/platform/auth/token) to restrict access by issuing tokens with specific capabilities to authorized users.
 * Specific `clientId` values in tokens to ensure only certain users can access particular channels.
 * Granting or restricting specific operations (`subscribe`, `publish`, `presence`) on channels through capability configurations.
 
@@ -87,7 +89,7 @@ Channel mode flags offer the ability for clients to use different capabilities f
 
 ## API key capabilities <a id="capabilities-key"/>
 
-An [Ably API key](/docs/auth#api-key) can have a single set of permissions, applied to any number of [channels](/docs/channels) or [queues](/docs/platform/integrations/queues).
+An [Ably API key](/docs/platform/auth#api-key) can have a single set of permissions, applied to any number of [channels](/docs/channels) or [queues](/docs/platform/integrations/queues).
 
 You can also choose whether to restrict the API key to only channels, only [queues](/docs/platform/integrations/queues), or to match a set of channel or queue names. If you've chosen to restrict the API key to *selected channels and queues*, you can use a comma separated list of resources the API key can access, making use of wildcards to provide access to areas of your app. It is worth noting an API key will provide the same permissions to all resources it has access to.
 
@@ -358,7 +360,7 @@ Note that a successful token request doesn't guarantee all requested capabilitie
 
 #### Ably Token without capabilities <a id="ably-token-all"/>
 
-If no capability is specified in an Ably `TokenRequest`, then the [Ably Token](/docs/auth/token/ably-tokens) will be given the full set of capabilities assigned to the issuing key.
+If no capability is specified in an Ably `TokenRequest`, then the [Ably Token](/docs/platform/auth/token/ably-tokens) will be given the full set of capabilities assigned to the issuing key.
 
 Using the following example, an API key exists with the listed capabilities. If an Ably Token is requested without specifying any capabilities then the `TokenRequest` is treated as requesting all capabilities, i.e. `{"[*]*":["*"]}`. This will result in the Ably Token receiving all the capabilities of the API key.
 
@@ -435,7 +437,7 @@ if err != nil {
 
 If a set of capabilities are requested, then the Ably Token will be assigned the intersection of the requested capability and the capability of the issuing key.
 
-Using the following example, an API key exists with the listed capabilities. If an [Ably Token](/docs/auth/token/ably-tokens) is requested and specifies a set of capabilities, then the resulting token will only receive those capabilities that intersect. The capabilities of a token cannot exceed those of the issuing API key.
+Using the following example, an API key exists with the listed capabilities. If an [Ably Token](/docs/platform/auth/token/ably-tokens) is requested and specifies a set of capabilities, then the resulting token will only receive those capabilities that intersect. The capabilities of a token cannot exceed those of the issuing API key.
 
 <Code>
 ```javascript
@@ -533,7 +535,7 @@ if err != nil {
 
 If a set of capabilities are requested, and the intersection between those and the API key's capabilities is empty, then the `TokenRequest` will result in an error.
 
-Using the following example, an API key exists with the listed capabilities. If an [Ably Token](/docs/auth/token/ably-tokens) is requested that specifies a set of capabilities, and there is no intersection between the capabilities of the issuing API key and requested token, then the token request will be rejected. In the following example, the callback will be returned with an error.
+Using the following example, an API key exists with the listed capabilities. If an [Ably Token](/docs/platform/auth/token/ably-tokens) is requested that specifies a set of capabilities, and there is no intersection between the capabilities of the issuing API key and requested token, then the token request will be rejected. In the following example, the callback will be returned with an error.
 
 <Code>
 ```javascript
@@ -595,15 +597,15 @@ if err != nil {
 
 #### Ably JWT capability determination <a id="ably-jwt"/>
 
-Capabilities are determined for [JWTs](/docs/auth/token/jwt) in the following way:
+Capabilities are determined for [JWTs](/docs/platform/auth/token/jwt) in the following way:
 
 * The capabilities granted to an Ably JWT will be the intersection of the capabilities within the Ably JWT and the capabilities of the associated API key.
 * If the set of capabilities within the Ably JWT have no intersection with the capabilities of the API key, then an error will instead be returned.
 
 ## Channel-scoped user claims <a id="custom-restrictions"/>
 
-JWTs can contain channel-scoped user claims for trusted metadata that other clients can read. See [JWT authentication — channel-scoped claims](/docs/auth/token/jwt#channel-claims) for details and examples.
+JWTs can contain channel-scoped user claims for trusted metadata that other clients can read. See [JWT authentication — channel-scoped claims](/docs/platform/auth/token/jwt#channel-claims) for details and examples.
 
 ## Per-connection publish rate limits <a id="jwt-limits"/>
 
-JWTs can specify per-connection publish rate limits to restrict how many messages a client can send. See [JWT authentication — rate limits](/docs/auth/token/jwt#rate-limits) for details and examples.
+JWTs can specify per-connection publish rate limits to restrict how many messages a client can send. See [JWT authentication — rate limits](/docs/platform/auth/token/jwt#rate-limits) for details and examples.
diff --git a/src/pages/docs/auth/identified-clients.mdx b/src/pages/docs/platform/auth/identified-clients.mdx
similarity index 79%
rename from src/pages/docs/auth/identified-clients.mdx
rename to src/pages/docs/platform/auth/identified-clients.mdx
index 6420260ee7..5df21052ce 100644
--- a/src/pages/docs/auth/identified-clients.mdx
+++ b/src/pages/docs/platform/auth/identified-clients.mdx
@@ -1,6 +1,8 @@
 ---
 title: Identified clients
 meta_description: "Clients can be allocated a client ID to help control their operations and interactions with Ably channels."
+redirect_from:
+  - /docs/auth/identified-clients
 ---
 
 When a client is authenticated and connected to Ably, it is considered to be an authenticated client. While an authenticated client has a means to authenticate with Ably, they do not necessarily have an identity.
@@ -33,18 +35,18 @@ There are three different ways a client can be identified with using a `clientId
 When a client sets their own ID there is the possibility that they can pretend to be someone else. To prevent this, it is recommended that you embed a `clientId` in the token issued to your clients from your auth server. This ensures that the `clientId` is set by your auth server, and eliminates the chance of a client pretending to be someone else.
 
 <Aside data-type='note'>
-Identifying a client varies depending on whether they are authenticating with basic authentication or token authentication. Token authentication is [recommended](/docs/auth#selecting-auth) in most instances so that clients authenticate using short-lived tokens and do not have access to API keys.
+Identifying a client varies depending on whether they are authenticating with basic authentication or token authentication. Token authentication is [recommended](/docs/platform/auth#selecting-auth) in most instances so that clients authenticate using short-lived tokens and do not have access to API keys.
 
 Since you then control the `clientId`, all other clients can rely on the validity of the `clientId` in published messages and of members present in presence channels. This eliminates the possibility of a client pretending to be someone else, as they cannot claim a `clientId` in their own.
 </Aside>
 
 ### Basic auth <a id="basic"/>
 
-You can use [basic authentication](/docs/auth/basic) to allow a client to claim any `clientId` when they authenticate with Ably. As the assignation of the `clientId` is not handled by a server, it cannot be trusted to represent the genuine identity of the client.
+You can use [basic authentication](/docs/platform/auth/basic) to allow a client to claim any `clientId` when they authenticate with Ably. As the assignation of the `clientId` is not handled by a server, it cannot be trusted to represent the genuine identity of the client.
 
 ### Token auth <a id="token"/>
 
-You can use [token authentication](/docs/auth/token) to set an explicit `clientId` when creating or issuing a token. Clients using that token are restricted to operations for only that `clientId`, and all operations will implicitly contain that `clientId`.
+You can use [token authentication](/docs/platform/auth/token) to set an explicit `clientId` when creating or issuing a token. Clients using that token are restricted to operations for only that `clientId`, and all operations will implicitly contain that `clientId`.
 
 For example, when publishing a message, the `clientId` attribute of the message will be pre-populated with that `clientId`. Entering presence will also implicitly use that `clientId`.
 
@@ -56,7 +58,7 @@ To set a `clientId` in a JWT, include the `x-ably-clientId` claim in the JWT pay
 | --- | --- |
 | `x-ably-clientId` | The `clientId` to assign to the client (for example, `user-123`). |
 
-See [JWT authentication](/docs/auth/token/jwt#scenario-standard) for complete server and client examples in all supported languages.
+See [JWT authentication](/docs/platform/auth/token/jwt#scenario-standard) for complete server and client examples in all supported languages.
 
 #### Using TokenRequest <a id="tokenrequest-clientid"/>
 
@@ -129,8 +131,8 @@ final tokenRequest = rest.auth.createTokenRequest(
 
 ### Wildcard token auth <a id="wildcard"/>
 
-You can use [token authentication](/docs/auth/token) to set a wildcard `clientId` using a value of `*` when creating a token. Clients are then able to assume any identity in their operations, such as when publishing a message or entering presence.
+You can use [token authentication](/docs/platform/auth/token) to set a wildcard `clientId` using a value of `*` when creating a token. Clients are then able to assume any identity in their operations, such as when publishing a message or entering presence.
 
 ## Unidentified clients <a id="unidentified"/>
 
-If no `clientId` is provided when using [token authentication](/docs/auth/token) then clients are not permitted to assume an identity and will be considered an unidentified client in all operations. Messages published will contain no `clientId` and those clients will not be permitted to enter the [presence](/docs/presence-occupancy/presence) set.
+If no `clientId` is provided when using [token authentication](/docs/platform/auth/token) then clients are not permitted to assume an identity and will be considered an unidentified client in all operations. Messages published will contain no `clientId` and those clients will not be permitted to enter the [presence](/docs/presence-occupancy/presence) set.
diff --git a/src/pages/docs/auth/index.mdx b/src/pages/docs/platform/auth/index.mdx
similarity index 70%
rename from src/pages/docs/auth/index.mdx
rename to src/pages/docs/platform/auth/index.mdx
index 88058a1694..61c8351485 100644
--- a/src/pages/docs/auth/index.mdx
+++ b/src/pages/docs/platform/auth/index.mdx
@@ -18,6 +18,7 @@ redirect_from:
   - /docs/general/authentication
   - /docs/general/_authentication_capabilities
   - /docs/ids-and-keys
+  - /docs/auth
 ---
 
 All interactions between a client and the Ably service must be authenticated.
@@ -26,18 +27,18 @@ All interactions between a client and the Ably service must be authenticated.
 
 | Environment | Recommended Method | Details |
 |-------------|-------------------|---------|
-| Client-side (browsers, mobile apps) | [Token authentication](/docs/auth/token) | Your server issues tokens ([JWT](/docs/auth/token/jwt) recommended); clients use `authCallback` to fetch them |
-| Server-side (Node.js, Python, etc.) | [Basic authentication](/docs/auth/basic) | Use your API key directly in trusted environments |
+| Client-side (browsers, mobile apps) | [Token authentication](/docs/platform/auth/token) | Your server issues tokens ([JWT](/docs/platform/auth/token/jwt) recommended); clients use `authCallback` to fetch them |
+| Server-side (Node.js, Python, etc.) | [Basic authentication](/docs/platform/auth/basic) | Use your API key directly in trusted environments |
 
 <Aside data-type='important'>
-Never use API keys in client-side code (that is, code that is not running in a server, but a client device such as a mobile or web app). API keys don't expire; once compromised, they grant indefinite access. Use [token authentication](/docs/auth/token) with tokens that have narrowly-scoped capabilities, are short-lived, and can be revoked.
+Never use API keys in client-side code (that is, code that is not running in a server, but a client device such as a mobile or web app). API keys don't expire; once compromised, they grant indefinite access. Use [token authentication](/docs/platform/auth/token) with tokens that have narrowly-scoped capabilities, are short-lived, and can be revoked.
 </Aside>
 
 ## Ably API keys <a id="api-keys"/>
 
 Every Ably app can have one or more API keys associated with it. API keys authenticate directly with Ably or are used to issue tokens.
 
-Keys can have different [capabilities](/docs/auth/capabilities), and tokens issued from a key can only request a subset of those capabilities.
+Keys can have different [capabilities](/docs/platform/auth/capabilities), and tokens issued from a key can only request a subset of those capabilities.
 
 ### API key format <a id="format"/>
 
@@ -58,8 +59,8 @@ To create an API key in the dashboard:
 1. Click the **API Keys** tab in your [dashboard](https://ably.com/accounts/any/apps/any/app_keys).
 2. Click **Create a new API key**.
 3. Enter a name to identify the key.
-4. Select the [capabilities](/docs/auth/capabilities) to apply.
-5. Optionally enable [token revocation](/docs/auth/revocation).
+4. Select the [capabilities](/docs/platform/auth/capabilities) to apply.
+5. Optionally enable [token revocation](/docs/platform/auth/revocation).
 6. Optionally restrict scope to specific channels or queues.
 
 <Aside data-type="note">
@@ -70,8 +71,8 @@ Code samples in this documentation use basic authentication for convenience. In
 
 Ably supports two authentication mechanisms:
 
-1. **[Token authentication](/docs/auth/token)**: Short-lived Ably Tokens that expire and can be revoked. Recommended for clients. Use [JWTs](/docs/auth/token/jwt) for most applications, or native [Ably Tokens](/docs/auth/token/ably-tokens) when JWTs aren't suitable.
-2. **[Basic authentication](/docs/auth/basic)**: Uses your API key directly. Use only on trusted servers.
+1. **[Token authentication](/docs/platform/auth/token)**: Short-lived Ably Tokens that expire and can be revoked. Recommended for clients. Use [JWTs](/docs/platform/auth/token/jwt) for most applications, or native [Ably Tokens](/docs/platform/auth/token/ably-tokens) when JWTs aren't suitable.
+2. **[Basic authentication](/docs/platform/auth/basic)**: Uses your API key directly. Use only on trusted servers.
 
 When deciding which method to use, apply the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege): a client should only possess the credentials and rights it needs. If credentials are compromised, the damage is minimized.
 
@@ -79,11 +80,11 @@ Many applications use a mixed strategy: trusted servers use basic authentication
 
 | Scenario | Recommended | Details |
 |----------|-------------|---------|
-| Client-side (browsers, mobile) | JWT | Use [JWT authentication](/docs/auth/token/jwt). No Ably SDK needed on your server |
-| Server-side (trusted environment) | Basic auth | Use your [API key](/docs/auth#api-keys) directly |
-| Fine-grained per-user access control | JWT or Ably Token | Set [capabilities](/docs/auth/capabilities) per token |
-| Time-limited or revocable access | JWT or Ably Token | Tokens expire and can be [revoked](/docs/auth/revocation) |
-| Channel-scoped user claims | JWT only | Embed trusted metadata via [channel-scoped claims](/docs/auth/token/jwt#channel-claims) |
-| Per-connection rate limits | JWT only | Restrict publish rates via [rate limit claims](/docs/auth/token/jwt#rate-limits) |
-| Large capability list or confidential capabilities | Ably Token | JWTs have size limits and can be decoded by clients. Use [Ably Tokens](/docs/auth/token/ably-tokens) |
-| Users must be identified | JWT or Ably Token | Set `clientId` server-side. See [identified clients](/docs/auth/identified-clients) |
+| Client-side (browsers, mobile) | JWT | Use [JWT authentication](/docs/platform/auth/token/jwt). No Ably SDK needed on your server |
+| Server-side (trusted environment) | Basic auth | Use your [API key](/docs/platform/auth#api-keys) directly |
+| Fine-grained per-user access control | JWT or Ably Token | Set [capabilities](/docs/platform/auth/capabilities) per token |
+| Time-limited or revocable access | JWT or Ably Token | Tokens expire and can be [revoked](/docs/platform/auth/revocation) |
+| Channel-scoped user claims | JWT only | Embed trusted metadata via [channel-scoped claims](/docs/platform/auth/token/jwt#channel-claims) |
+| Per-connection rate limits | JWT only | Restrict publish rates via [rate limit claims](/docs/platform/auth/token/jwt#rate-limits) |
+| Large capability list or confidential capabilities | Ably Token | JWTs have size limits and can be decoded by clients. Use [Ably Tokens](/docs/platform/auth/token/ably-tokens) |
+| Users must be identified | JWT or Ably Token | Set `clientId` server-side. See [identified clients](/docs/platform/auth/identified-clients) |
diff --git a/src/pages/docs/auth/revocation.mdx b/src/pages/docs/platform/auth/revocation.mdx
similarity index 97%
rename from src/pages/docs/auth/revocation.mdx
rename to src/pages/docs/platform/auth/revocation.mdx
index dad67730ee..423a17632a 100644
--- a/src/pages/docs/auth/revocation.mdx
+++ b/src/pages/docs/platform/auth/revocation.mdx
@@ -1,6 +1,8 @@
 ---
 title: Token revocation
 meta_description: "Token revocation is a mechanism that enables an app to invalidate authentication tokens."
+redirect_from:
+  - /docs/auth/revocation
 ---
 
 Token revocation is a mechanism that enables an app to invalidate authentication tokens. This invalidation can be used to force specified clients to re-obtain a token, and subsequently enables the app to modify the rights granted to clients, or to decline to re-issue a token. Token revocation can be enforced immediately or postponed by 30 seconds, allowing the client the opportunity to request a new token (see `allowReauthMargin` under [Revoke a token](#revoke)). By default `allowReauthMargin` is set to false, meaning token revocation is near immediate. Setting this value to true would postpone the revocation by 30 seconds.
@@ -20,7 +22,7 @@ To enable token revocation for an API key:
 3. Open the **Settings** for an existing API key or **Create a new API key**.
 4. Check the **Revocable tokens** field:
 
-![Token revocation settings](../../../images/content/screenshots/token-revocation.png)
+![Token revocation settings](../../../../images/content/screenshots/token-revocation.png)
 
 **Note:** Token revocation can only revoke tokens that were issued by an API key that had revocable tokens enabled before the token was issued.
 
@@ -233,7 +235,7 @@ In this example, all users that have been assigned the revocation key `users.gro
 
 ### channel <a id="channel"/>
 
-This target specifier will match tokens that exactly match one of the resource names present in the token [capabilities](/docs/auth/capabilities). Note that this is not the same thing as revoking all tokens that have access to the channel.
+This target specifier will match tokens that exactly match one of the resource names present in the token [capabilities](/docs/platform/auth/capabilities). Note that this is not the same thing as revoking all tokens that have access to the channel.
 
 For example, a token with a capability of `{"foo:*": ["*"]}` will be revoked by a target of `channel:foo:*`, but a revocation to `channel:*:*` will have no effect (even though that is a superset of the capabilities of `foo:*`), and nor will `channel:foo:bar` (even for connections using the token to attach to that particular channel). It must be the exact string used in the token capabilities (which may be inherited from key capabilities).
 
diff --git a/src/pages/docs/auth/token/ably-tokens.mdx b/src/pages/docs/platform/auth/token/ably-tokens.mdx
similarity index 95%
rename from src/pages/docs/auth/token/ably-tokens.mdx
rename to src/pages/docs/platform/auth/token/ably-tokens.mdx
index bc97bd66e1..453acc88af 100644
--- a/src/pages/docs/auth/token/ably-tokens.mdx
+++ b/src/pages/docs/platform/auth/token/ably-tokens.mdx
@@ -2,19 +2,21 @@
 title: "Ably Tokens"
 meta_description: "Ably Tokens are an alternative to JWTs when you need to keep capabilities confidential or when your capability list is very large."
 meta_keywords: "Ably Token, TokenRequest, token authentication, native token, capabilities, token request, embedded token JWT"
+redirect_from:
+  - /docs/auth/token/ably-tokens
 ---
 
 Ably tokens are an alternative mechanism for authenticating with Ably.
 
 They are not generated by a client but are issued by the Ably service via a `/requestToken` endpoint; a client generates a signed `Token Request` and this is exchanged for a token by the Ably service. Generally, integrating an application to use Ably tokens is more involved as Ably tokens also do not support all of the functionality available to JWTs.
 
-[JWTs](/docs/auth/token/jwt) are the recommended mechanism for authenticating with Ably, however there are still some circumstances where the use of Ably tokens may be preferred:
+[JWTs](/docs/platform/auth/token/jwt) are the recommended mechanism for authenticating with Ably, however there are still some circumstances where the use of Ably tokens may be preferred:
 
 - Your capability list is too large and exceeds JWT size limits (JWTs must fit within HTTP header limits, typically around 8 KB).
 - You need to keep your capability list confidential, as JWTs can be decoded by clients.
 
 <Aside data-type='note'>
-JWTs are recommended for most use cases. JWTs require no Ably SDK on your server and support [channel-scoped claims](/docs/auth/token/jwt#channel-claims) and [per-connection rate limits](/docs/auth/token/jwt#rate-limits).
+JWTs are recommended for most use cases. JWTs require no Ably SDK on your server and support [channel-scoped claims](/docs/platform/auth/token/jwt#channel-claims) and [per-connection rate limits](/docs/platform/auth/token/jwt#rate-limits).
 </Aside>
 
 ## Choosing between TokenRequest and Ably Token (direct)
@@ -53,7 +55,7 @@ Key characteristics:
 
 Using an Ably SDK, a `TokenRequest` is [generated from your server](/docs/api/realtime-sdk/authentication#create-token-request) and returned to the client-side SDK instance. The client-side SDK instance then uses the [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) to request an Ably Token from Ably.
 
-![Ably TokenRequest auth process diagram](../../../../images/content/diagrams/Ably-token-auth-1.png)
+![Ably TokenRequest auth process diagram](../../../../../images/content/diagrams/Ably-token-auth-1.png)
 
 Key characteristics:
 
@@ -261,7 +263,7 @@ final realtime = ably.Realtime(options: clientOptions);
 
 Using an Ably SDK, an Ably Token is [requested by your server](/docs/api/realtime-sdk/authentication#request-token) from Ably and then passed to the client. The client uses this token directly to authenticate. The client does not need to make an additional round trip to Ably.
 
-![Ably token auth process diagram](../../../../images/content/diagrams/Ably-Auth-Overview1.png)
+![Ably token auth process diagram](../../../../../images/content/diagrams/Ably-Auth-Overview1.png)
 
 Having the server obtain the token directly is generally more reliable. It minimizes the time delay between creation of the TokenRequest and requesting the token, and eliminates reliance on the accuracy of the clock in the client.
 
@@ -463,4 +465,4 @@ final realtime = ably.Realtime(options: clientOptions);
 ```
 </Code>
 
-For embedded token JWTs, where you embed an Ably Token within an outer JWT used by your existing authentication system, see [Embedded Token JWT](/docs/auth/token#embedded).
+For embedded token JWTs, where you embed an Ably Token within an outer JWT used by your existing authentication system, see [Embedded Token JWT](/docs/platform/auth/token#embedded).
diff --git a/src/pages/docs/auth/token/index.mdx b/src/pages/docs/platform/auth/token/index.mdx
similarity index 90%
rename from src/pages/docs/auth/token/index.mdx
rename to src/pages/docs/platform/auth/token/index.mdx
index c9274690d0..7823e5b4bf 100644
--- a/src/pages/docs/auth/token/index.mdx
+++ b/src/pages/docs/platform/auth/token/index.mdx
@@ -1,9 +1,11 @@
 ---
 title: "Token auth"
 meta_description: "Token authentication allows clients to authenticate with Ably, without exposing the Ably API key and secret."
+redirect_from:
+  - /docs/auth/token
 ---
 
-Token authentication uses a trusted device with an [API key](/docs/auth#api-key) to issue time-limited tokens to untrusted clients. Tokens have a limited set of access rights, known as [capabilities](/docs/auth/capabilities), and can have a specific [identity](/docs/auth/identified-clients) using a `clientId`.
+Token authentication uses a trusted device with an [API key](/docs/platform/auth#api-key) to issue time-limited tokens to untrusted clients. Tokens have a limited set of access rights, known as [capabilities](/docs/platform/auth/capabilities), and can have a specific [identity](/docs/platform/auth/identified-clients) using a `clientId`.
 
 Token authentication is the recommended authentication method to use client-side for the following reasons:
 
@@ -22,18 +24,18 @@ Ably supports two token formats: JWT, the primary and recommended format, and Ab
 
 ### JWT format (recommended)
 
-[JWTs](/docs/auth/token/jwt) are the recommended approach for most applications:
+[JWTs](/docs/platform/auth/token/jwt) are the recommended approach for most applications:
 
 - No Ably SDK required on your server. Any JWT library works.
-- Supports [channel-scoped claims](/docs/auth/token/jwt#channel-claims) for trusted metadata
-- Supports [per-connection rate limits](/docs/auth/token/jwt#rate-limits)
+- Supports [channel-scoped claims](/docs/platform/auth/token/jwt#channel-claims) for trusted metadata
+- Supports [per-connection rate limits](/docs/platform/auth/token/jwt#rate-limits)
 - Stateless and ideal for serverless environments
 
 Use JWTs unless your capability list is very large (JWTs must fit within HTTP header limits, typically around 8 KB) or you need to keep capabilities confidential (clients can decode JWTs).
 
 ### Native Ably Token formats
 
-[Ably tokens](/docs/auth/token/ably-tokens) are an alternative mechanism that predates Ably's JWT support. Unlike JWTs, Ably tokens are not generated by a client but are issued by the Ably service via a `/requestToken` endpoint. Integrating Ably tokens is more involved, and they do not support all functionality available with JWTs. Use native [Ably Tokens](/docs/auth/token/ably-tokens) when JWTs are not suitable:
+[Ably tokens](/docs/platform/auth/token/ably-tokens) are an alternative mechanism that predates Ably's JWT support. Unlike JWTs, Ably tokens are not generated by a client but are issued by the Ably service via a `/requestToken` endpoint. Integrating Ably tokens is more involved, and they do not support all functionality available with JWTs. Use native [Ably Tokens](/docs/platform/auth/token/ably-tokens) when JWTs are not suitable:
 
 - TokenRequest: Server creates a signed request locally, client exchanges it with Ably
 - Ably Token (direct): Server requests token from Ably, passes it to client
@@ -62,7 +64,7 @@ Ably enforces maximum TTL (time-to-live) limits:
 
 - Access tokens: Maximum TTL of 24 hours.
 - Device tokens (for push notifications): Maximum TTL of 5 years.
-- Revocable tokens: Maximum TTL of 1 hour. A token is revocable if [token revocation](/docs/auth/revocation) has been enabled for the API key used to issue it.
+- Revocable tokens: Maximum TTL of 1 hour. A token is revocable if [token revocation](/docs/platform/auth/revocation) has been enabled for the API key used to issue it.
 
 <Aside data-type="important">
 Attempting to create a token with a TTL that exceeds these limits will result in an error code [40003](/docs/platform/errors/codes#40003).
@@ -70,7 +72,7 @@ Attempting to create a token with a TTL that exceeds these limits will result in
 
 ## Dynamic channel access control <a id="dynamic-access"/>
 
-Token authentication allows you to dynamically change a client's channel access permissions without disconnecting. Use the [`authorize()`](/docs/api/realtime-sdk/authentication#authorize) method to re-authenticate with updated [capabilities](/docs/auth/capabilities).
+Token authentication allows you to dynamically change a client's channel access permissions without disconnecting. Use the [`authorize()`](/docs/api/realtime-sdk/authentication#authorize) method to re-authenticate with updated [capabilities](/docs/platform/auth/capabilities).
 
 When you call `client.auth.authorize()`:
 
@@ -210,7 +212,7 @@ print('Successfully updated permissions');
 
 For security purposes, handle non-compliant clients by:
 - Set shorter token TTL expiry times to force frequent re-authentication (minimum 10 minutes recommended).
-- Use the [token revocation API](/docs/auth/revocation) to immediately invalidate tokens.
+- Use the [token revocation API](/docs/platform/auth/revocation) to immediately invalidate tokens.
 
 <Aside data-type="important">
 The `authorize()` method maintains the existing connection while updating permissions, making it ideal for real-time applications where connection continuity is important.
@@ -241,7 +243,7 @@ Token authentication with server-side validation is recommended over API key res
 
 If you have an existing [JWT](https://jwt.io/) authentication system, you can embed an Ably Token as a claim within your JWT. This allows you to use your existing auth infrastructure while providing Ably authentication.
 
-![Token embedded in a JWT auth method](../../../../images/content/diagrams/Ably-Auth-Overview3.png)
+![Token embedded in a JWT auth method](../../../../../images/content/diagrams/Ably-Auth-Overview3.png)
 
 ### Requirements
 
@@ -463,8 +465,8 @@ Providing a literal `token` or `tokenDetails` is typically used for testing: sin
 
 ## Next steps
 
-- [JWTs](/docs/auth/token/jwt) - Recommended approach for most applications
-- [Ably Tokens](/docs/auth/token/ably-tokens) - Alternative when JWTs aren't suitable
-- [Capabilities](/docs/auth/capabilities) - Control what operations clients can perform
-- [Identified clients](/docs/auth/identified-clients) - Assign trusted identities to clients
-- [Token revocation](/docs/auth/revocation) - Immediately invalidate tokens
+- [JWTs](/docs/platform/auth/token/jwt) - Recommended approach for most applications
+- [Ably Tokens](/docs/platform/auth/token/ably-tokens) - Alternative when JWTs aren't suitable
+- [Capabilities](/docs/platform/auth/capabilities) - Control what operations clients can perform
+- [Identified clients](/docs/platform/auth/identified-clients) - Assign trusted identities to clients
+- [Token revocation](/docs/platform/auth/revocation) - Immediately invalidate tokens
diff --git a/src/pages/docs/auth/token/jwt.mdx b/src/pages/docs/platform/auth/token/jwt.mdx
similarity index 97%
rename from src/pages/docs/auth/token/jwt.mdx
rename to src/pages/docs/platform/auth/token/jwt.mdx
index e5b660bc77..91c208637d 100644
--- a/src/pages/docs/auth/token/jwt.mdx
+++ b/src/pages/docs/platform/auth/token/jwt.mdx
@@ -2,15 +2,17 @@
 title: "JSON Web Tokens (JWTs)"
 meta_description: "JWT authentication is the recommended approach for authenticating clients with Ably. Create JWTs signed with your Ably API key."
 meta_keywords: "JWT, JSON Web Token, Ably authentication, token auth, authCallback, authUrl, JWT claims, channel claims, rate limits"
+redirect_from:
+  - /docs/auth/token/jwt
 ---
 
 JSON Web Token (JWT) is the recommended token format for most applications. Your clients request a JWT from your server, which creates and signs it using your Ably API key. No Ably SDK is required on the server — any JWT library works.
 
 <Aside data-type='note'>
-Use native [Ably Tokens](/docs/auth/token/ably-tokens) when:
+Use native [Ably Tokens](/docs/platform/auth/token/ably-tokens) when:
 - Your capability list is too large and exceeds JWT size limits. JWTs must fit within HTTP header limits, typically around 8 KB.
 - You need to keep your capability list confidential, as JWTs can be decoded by clients.
-- You already have a JWT-based auth system and want to embed Ably tokens within your existing JWTs. See [Embedded Token JWT](/docs/auth/token#embedded).
+- You already have a JWT-based auth system and want to embed Ably tokens within your existing JWTs. See [Embedded Token JWT](/docs/platform/auth/token#embedded).
 </Aside>
 
 ## Server setup <a id="scenario-standard"/>
@@ -221,8 +223,8 @@ Ably does not support asymmetric signatures based on a key pair belonging to a t
 
 | Claim | Required | Description |
 |-------|----------|-------------|
-| `x-ably-capability` | Yes | JSON string defining [capabilities](/docs/auth/capabilities) |
-| `x-ably-clientId` | No | Sets a trusted [client ID](/docs/auth/identified-clients) |
+| `x-ably-capability` | Yes | JSON string defining [capabilities](/docs/platform/auth/capabilities) |
+| `x-ably-clientId` | No | Sets a trusted [client ID](/docs/platform/auth/identified-clients) |
 | `exp` | Yes | Expiration time (Unix timestamp) |
 | `iat` | Yes | Issued at time (Unix timestamp) |
 
@@ -662,11 +664,11 @@ const ablyJwt = jwt.sign(
 </Code>
 
 <Aside data-type='important'>
-**JWT-only features:** Channel-scoped claims and per-connection rate limits are only available with JWTs. If you use [Ably Tokens](/docs/auth/token/ably-tokens), you will not have access to these features.
+**JWT-only features:** Channel-scoped claims and per-connection rate limits are only available with JWTs. If you use [Ably Tokens](/docs/platform/auth/token/ably-tokens), you will not have access to these features.
 </Aside>
 
 ## Token lifecycle
 
-Token refresh, TTL limits, and dynamic access control apply to all token types. See [token authentication](/docs/auth/token#refresh) for details.
+Token refresh, TTL limits, and dynamic access control apply to all token types. See [token authentication](/docs/platform/auth/token#refresh) for details.
 
-For a comparison of JWT, TokenRequest, and Ably Token mechanisms, see [choosing a token mechanism](/docs/auth/token#choosing).
+For a comparison of JWT, TokenRequest, and Ably Token mechanisms, see [choosing a token mechanism](/docs/platform/auth/token#choosing).

From 3816ebaa4c37ada7d6c68bb3db45915d1919b495 Mon Sep 17 00:00:00 2001
From: umair <umair.hussain@ably.com>
Date: Thu, 5 Mar 2026 12:52:31 +0000
Subject: [PATCH 2/3] Migrate internal links from /docs/auth to
 /docs/platform/auth

Update ~604 link references across ~111 MDX files to reflect the new
canonical location of auth documentation under /platform/auth.
---
 src/pages/docs/ai-transport/index.mdx         |   2 +-
 .../docs/ai-transport/messaging/citations.mdx |   2 +-
 .../messaging/human-in-the-loop.mdx           |   2 +-
 .../identifying-users-and-agents.mdx          |  28 +--
 .../sessions-identity/online-status.mdx       |   6 +-
 .../sessions-identity/push-notifications.mdx  |   2 +-
 .../sessions-identity/resuming-sessions.mdx   |   2 +-
 .../token-streaming/message-per-response.mdx  |   2 +-
 src/pages/docs/api/realtime-sdk.mdx           | 106 +++++------
 .../docs/api/realtime-sdk/authentication.mdx  |  50 +++---
 src/pages/docs/api/realtime-sdk/channels.mdx  |  10 +-
 src/pages/docs/api/realtime-sdk/presence.mdx  |   2 +-
 .../docs/api/realtime-sdk/push-admin.mdx      |  20 +--
 src/pages/docs/api/realtime-sdk/push.mdx      |  10 +-
 src/pages/docs/api/realtime-sdk/types.mdx     | 142 +++++++--------
 src/pages/docs/api/rest-api.mdx               |  14 +-
 src/pages/docs/api/rest-sdk.mdx               | 106 +++++------
 .../docs/api/rest-sdk/authentication.mdx      |  56 +++---
 src/pages/docs/api/rest-sdk/channels.mdx      |  10 +-
 src/pages/docs/api/rest-sdk/push-admin.mdx    |  20 +--
 src/pages/docs/api/rest-sdk/types.mdx         | 168 +++++++++---------
 src/pages/docs/api/token-request-spec.mdx     |   6 +-
 src/pages/docs/channels/index.mdx             |  10 +-
 .../docs/channels/options/encryption.mdx      |   2 +-
 src/pages/docs/channels/options/index.mdx     |   4 +-
 src/pages/docs/channels/states.mdx            |   2 +-
 .../docs/chat/api/javascript/chat-client.mdx  |   2 +-
 .../chat/api/javascript/message-reactions.mdx |   2 +-
 .../docs/chat/api/javascript/message.mdx      |   2 +-
 .../docs/chat/api/javascript/presence.mdx     |   2 +-
 .../chat/api/javascript/room-reactions.mdx    |   2 +-
 src/pages/docs/chat/api/javascript/typing.mdx |   4 +-
 src/pages/docs/chat/authentication.mdx        |   4 +-
 .../docs/chat/getting-started/android.mdx     |   4 +-
 .../docs/chat/getting-started/javascript.mdx  |   4 +-
 src/pages/docs/chat/getting-started/jvm.mdx   |   4 +-
 .../chat/getting-started/react-native.mdx     |   4 +-
 .../chat/getting-started/react-ui-kit.mdx     |   4 +-
 src/pages/docs/chat/getting-started/react.mdx |   4 +-
 .../getting-started/swift-async-sequence.mdx  |   4 +-
 src/pages/docs/chat/getting-started/swift.mdx |   4 +-
 src/pages/docs/chat/index.mdx                 |   2 +-
 src/pages/docs/chat/setup.mdx                 |  18 +-
 src/pages/docs/connect/index.mdx              |   2 +-
 src/pages/docs/connect/states.mdx             |   2 +-
 src/pages/docs/faq/index.mdx                  |   4 +-
 src/pages/docs/faq/push-faqs.mdx              |   8 +-
 src/pages/docs/getting-started/dotnet.mdx     |   6 +-
 src/pages/docs/getting-started/flutter.mdx    |   6 +-
 src/pages/docs/getting-started/go.mdx         |   4 +-
 src/pages/docs/getting-started/java.mdx       |   6 +-
 src/pages/docs/getting-started/javascript.mdx |   4 +-
 src/pages/docs/getting-started/kotlin.mdx     |   4 +-
 src/pages/docs/getting-started/node.mdx       |   4 +-
 .../docs/getting-started/objective-c.mdx      |   6 +-
 src/pages/docs/getting-started/php.mdx        |   4 +-
 src/pages/docs/getting-started/python.mdx     |   4 +-
 .../docs/getting-started/react-hooks.mdx      |   4 +-
 .../docs/getting-started/react-native.mdx     |   6 +-
 src/pages/docs/getting-started/react.mdx      |   4 +-
 src/pages/docs/getting-started/ruby.mdx       |   6 +-
 src/pages/docs/getting-started/swift.mdx      |   4 +-
 .../docs/guides/chat/build-livestream.mdx     |   2 +-
 .../pub-sub/dashboards-and-visualizations.mdx |   4 +-
 .../docs/liveobjects/concepts/operations.mdx  |   2 +-
 src/pages/docs/liveobjects/inband-objects.mdx |   2 +-
 .../docs/liveobjects/quickstart/java.mdx      |   8 +-
 .../liveobjects/quickstart/javascript.mdx     |   8 +-
 .../docs/liveobjects/quickstart/swift.mdx     |   8 +-
 src/pages/docs/liveobjects/rest-api-usage.mdx |   2 +-
 src/pages/docs/livesync/index.mdx             |   2 +-
 src/pages/docs/livesync/mongodb/index.mdx     |   6 +-
 src/pages/docs/livesync/postgres/models.mdx   |   8 +-
 .../docs/livesync/postgres/quickstart.mdx     |   2 +-
 src/pages/docs/messages/annotations.mdx       |  10 +-
 src/pages/docs/messages/index.mdx             |   2 +-
 src/pages/docs/messages/updates-deletes.mdx   |  16 +-
 .../docs/metadata-stats/metadata/rest.mdx     |   4 +-
 .../metadata-stats/metadata/subscribe.mdx     |   2 +-
 src/pages/docs/metadata-stats/stats.mdx       |   2 +-
 src/pages/docs/platform/account/app/api.mdx   |  12 +-
 .../docs/platform/account/control-api.mdx     |   4 +-
 .../account/enterprise-customization.mdx      |   2 +-
 src/pages/docs/platform/account/users.mdx     |   2 +-
 src/pages/docs/platform/ai-llms/index.mdx     |   4 +-
 src/pages/docs/platform/errors/codes.mdx      |  66 +++----
 .../integrations/inbound/kafka-connector.mdx  |   2 +-
 .../integrations/skip-integrations.mdx        |   2 +-
 src/pages/docs/platform/pricing/limits.mdx    |   2 +-
 src/pages/docs/platform/products/index.mdx    |   4 +-
 .../docs/presence-occupancy/presence.mdx      |   4 +-
 src/pages/docs/protocols/index.mdx            |   2 +-
 src/pages/docs/protocols/mqtt.mdx             |   6 +-
 src/pages/docs/protocols/pubnub.mdx           |   2 +-
 src/pages/docs/protocols/pusher.mdx           |   4 +-
 src/pages/docs/protocols/sse.mdx              |   6 +-
 src/pages/docs/pub-sub/advanced.mdx           |   8 +-
 src/pages/docs/pub-sub/index.mdx              |   2 +-
 src/pages/docs/push/getting-started/apns.mdx  |   2 +-
 src/pages/docs/push/getting-started/fcm.mdx   |   2 +-
 src/pages/docs/push/getting-started/web.mdx   |   2 +-
 src/pages/docs/push/index.mdx                 |   2 +-
 src/pages/docs/spaces/authentication.mdx      |   4 +-
 src/pages/docs/spaces/avatar.mdx              |   2 +-
 src/pages/docs/spaces/cursors.mdx             |   2 +-
 src/pages/docs/spaces/index.mdx               |   2 +-
 src/pages/docs/spaces/locations.mdx           |   2 +-
 src/pages/docs/spaces/locking.mdx             |   2 +-
 src/pages/docs/spaces/react.mdx               |   4 +-
 src/pages/docs/spaces/setup.mdx               |  14 +-
 src/pages/docs/spaces/space.mdx               |   2 +-
 111 files changed, 604 insertions(+), 604 deletions(-)

diff --git a/src/pages/docs/ai-transport/index.mdx b/src/pages/docs/ai-transport/index.mdx
index 9b4e25aa0c..d67391d01d 100644
--- a/src/pages/docs/ai-transport/index.mdx
+++ b/src/pages/docs/ai-transport/index.mdx
@@ -165,7 +165,7 @@ It also puts you in control of how you manage your application when there aren't
 
 ### Enterprise controls <a id="enterprise"/>
 
-Ably's platform provides [integrations](/docs/platform/integrations) and functionality to ensure that your applications always exceed the requirements of enterprise environments. Whether that's [message auditing](/docs/platform/integrations/streaming), [client identification](/docs/auth/identified-clients) or [fine-grained authorization](/docs/auth/capabilities).
+Ably's platform provides [integrations](/docs/platform/integrations) and functionality to ensure that your applications always exceed the requirements of enterprise environments. Whether that's [message auditing](/docs/platform/integrations/streaming), [client identification](/docs/platform/auth/identified-clients) or [fine-grained authorization](/docs/platform/auth/capabilities).
 
 ## Examples
 
diff --git a/src/pages/docs/ai-transport/messaging/citations.mdx b/src/pages/docs/ai-transport/messaging/citations.mdx
index 71a78fb866..70f1dfaf02 100644
--- a/src/pages/docs/ai-transport/messaging/citations.mdx
+++ b/src/pages/docs/ai-transport/messaging/citations.mdx
@@ -306,7 +306,7 @@ The `multiple.v1` summary groups counts by the annotation `name`, with totals an
 ```
 </Code>
 
-When agents publish citations with a [`clientId`](/docs/auth/identified-clients), summaries include a per-client count showing how many citations each agent contributed. Citations published by [unidentified](/docs/auth/identified-clients#unidentified) clients are counted in the `totalUnidentified` field.
+When agents publish citations with a [`clientId`](/docs/platform/auth/identified-clients), summaries include a per-client count showing how many citations each agent contributed. Citations published by [unidentified](/docs/platform/auth/identified-clients#unidentified) clients are counted in the `totalUnidentified` field.
 
 <Aside data-type="note">
 The `clipped` field indicates whether the summary was truncated due to size limits. This only occurs when a large number of clients with distinct `clientId`s publish annotations. See [large summaries](/docs/messages/annotations#large-summaries) for more information.
diff --git a/src/pages/docs/ai-transport/messaging/human-in-the-loop.mdx b/src/pages/docs/ai-transport/messaging/human-in-the-loop.mdx
index 8428724be9..6382fef18f 100644
--- a/src/pages/docs/ai-transport/messaging/human-in-the-loop.mdx
+++ b/src/pages/docs/ai-transport/messaging/human-in-the-loop.mdx
@@ -330,7 +330,7 @@ channel.subscribe("approval-response", message -> {
 
 ### Verify by role <a id="verify-role"/>
 
-Use [user claims](/docs/auth/capabilities#custom-restrictions-on-channels-) to embed roles directly in the JWT for role-based access control (RBAC). This approach is useful when permissions are role-based rather than user-specific, allowing you to make authorization decisions based on the user's role without looking up individual user permissions.
+Use [user claims](/docs/platform/auth/capabilities#custom-restrictions-on-channels-) to embed roles directly in the JWT for role-based access control (RBAC). This approach is useful when permissions are role-based rather than user-specific, allowing you to make authorization decisions based on the user's role without looking up individual user permissions.
 
 <Aside data-type="note">
 This approach uses [authenticated claims for users](/docs/ai-transport/sessions-identity/identifying-users-and-agents#user-claims) to embed custom claims in JWTs that represent user roles or attributes.
diff --git a/src/pages/docs/ai-transport/sessions-identity/identifying-users-and-agents.mdx b/src/pages/docs/ai-transport/sessions-identity/identifying-users-and-agents.mdx
index 5a43b61ddd..f0c0c6a41c 100644
--- a/src/pages/docs/ai-transport/sessions-identity/identifying-users-and-agents.mdx
+++ b/src/pages/docs/ai-transport/sessions-identity/identifying-users-and-agents.mdx
@@ -17,9 +17,9 @@ In decoupled architectures, identity serves several critical purposes:
 
 ## Authenticating users <a id="authenticating"/>
 
-Use [token authentication](/docs/auth/token) to authenticate users securely. Your authentication server generates a token that is signed with the secret part of your Ably API key. Clients use this token to connect to Ably, and the token signature ensures it cannot be tampered with.
+Use [token authentication](/docs/platform/auth/token) to authenticate users securely. Your authentication server generates a token that is signed with the secret part of your Ably API key. Clients use this token to connect to Ably, and the token signature ensures it cannot be tampered with.
 
-The following examples use [JWT authentication](/docs/auth/token#jwt) for its simplicity and standard tooling support. For other approaches, see [token authentication](/docs/auth/token).
+The following examples use [JWT authentication](/docs/platform/auth/token#jwt) for its simplicity and standard tooling support. For other approaches, see [token authentication](/docs/platform/auth/token).
 
 Create a server endpoint that generates signed JWTs after verifying user authentication:
 
@@ -179,10 +179,10 @@ The `authenticateUser` middleware in this example is for demonstration purposes
 
 The JWT is signed with the secret part of your Ably API key using [HMAC-SHA-256](https://datatracker.ietf.org/doc/html/rfc4868). This example does not embed any claims in the JWT payload, so by default the token inherits the capabilities of the Ably API key used to sign the token.
 
-Configure your client to obtain a signed JWT from your server endpoint using an [`authCallback`](/docs/auth/token#auth-callback). The client obtains a signed JWT from the callback and uses it to authenticate requests to Ably. The client automatically makes a request for a new token before it expires.
+Configure your client to obtain a signed JWT from your server endpoint using an [`authCallback`](/docs/platform/auth/token#auth-callback). The client obtains a signed JWT from the callback and uses it to authenticate requests to Ably. The client automatically makes a request for a new token before it expires.
 
 <Aside data-type="important">
-Never include your Ably API key in client code. Instead, always authenticate clients using [token auth](/docs/auth/token).
+Never include your Ably API key in client code. Instead, always authenticate clients using [token auth](/docs/platform/auth/token).
 </Aside>
 
 <Code>
@@ -244,7 +244,7 @@ ably.connection.on(ConnectionState.connected, state -> {
 
 ## Authenticating agents <a id="authenticating-agents"/>
 
-Agents typically run on servers in trusted environments where API keys can be securely stored. Use [API key authentication](/docs/auth#basic-authentication) to authenticate agents directly with Ably.
+Agents typically run on servers in trusted environments where API keys can be securely stored. Use [API key authentication](/docs/platform/auth#basic-authentication) to authenticate agents directly with Ably.
 
 <Code>
 ```javascript
@@ -287,12 +287,12 @@ Only use API key authentication in server-side code. Never include your Ably API
 </Aside>
 
 <Aside data-type="note">
-Agents can also authenticate using [token authentication](/docs/auth/token), which is useful when agents run in environments where API keys should not be stored or when agents need dynamic capabilities that change based on runtime conditions.
+Agents can also authenticate using [token authentication](/docs/platform/auth/token), which is useful when agents run in environments where API keys should not be stored or when agents need dynamic capabilities that change based on runtime conditions.
 </Aside>
 
 ## Specifying capabilities <a id="capabilities"/>
 
-Use [capabilities](/docs/auth/capabilities) to specify which operations clients can perform on which channels. This applies to both users and agents, allowing you to enforce fine-grained permissions.
+Use [capabilities](/docs/platform/auth/capabilities) to specify which operations clients can perform on which channels. This applies to both users and agents, allowing you to enforce fine-grained permissions.
 
 ### User capabilities <a id="user-capabilities"/>
 
@@ -409,7 +409,7 @@ announcementsChannel.subscribe(msg -> System.out.println(msg)); // succeeds
 </Code>
 
 <Aside data-type="note">
-Ably recommends using token authentication with short-lived tokens and minimal capabilities required for each user to limit the window of exposure if a token is compromised. For more information, see [When to use token auth](/docs/auth/token#when).
+Ably recommends using token authentication with short-lived tokens and minimal capabilities required for each user to limit the window of exposure if a token is compromised. For more information, see [When to use token auth](/docs/platform/auth/token#when).
 </Aside>
 
 ### Agent capabilities <a id="agent-capabilities"/>
@@ -479,12 +479,12 @@ Following the principle of least privilege, provision API keys with the minimum
 
 Use the [`clientId`](/docs/messages#properties) to identify the user or agent that published a message. The method for setting `clientId` depends on your authentication approach:
 
-- When using [basic authentication](/docs/auth/identified-clients#basic), specify the `clientId` directly in the client options when instantiating the client instance.
-- When using [token authentication](/docs/auth/identified-clients#token), specify an explicit `clientId` when issuing the token.
+- When using [basic authentication](/docs/platform/auth/identified-clients#basic), specify the `clientId` directly in the client options when instantiating the client instance.
+- When using [token authentication](/docs/platform/auth/identified-clients#token), specify an explicit `clientId` when issuing the token.
 
 ### User identity <a id="user-identity"/>
 
-Users typically authenticate using [token authentication](/docs/auth/identified-clients#token). Add the [`x-ably-clientId`](/docs/api/realtime-sdk/authentication#ably-jwt) claim to your JWT to establish a verified identity for each user client. This identity appears as the [`clientId`](/docs/messages#properties) in all messages the user publishes, and subscribers can trust this identity because only your server can issue JWTs with specific `clientId` values.
+Users typically authenticate using [token authentication](/docs/platform/auth/identified-clients#token). Add the [`x-ably-clientId`](/docs/api/realtime-sdk/authentication#ably-jwt) claim to your JWT to establish a verified identity for each user client. This identity appears as the [`clientId`](/docs/messages#properties) in all messages the user publishes, and subscribers can trust this identity because only your server can issue JWTs with specific `clientId` values.
 
 As with all clients, the method for setting `clientId` depends on your [authentication approach](#identity).
 
@@ -608,7 +608,7 @@ The `clientId` in the message can be trusted, so agents can use this identity to
 
 ### Agent identity <a id="agent-identity"/>
 
-Agent code typically runs in a trusted environment, so you can use [basic authentication](/docs/auth/identified-clients#basic) and directly specify the `clientId` when instantiating the agent client. This identity appears as the [`clientId`](/docs/messages#properties) in all messages the agent publishes, allowing subscribers to identify the agent which published a message.
+Agent code typically runs in a trusted environment, so you can use [basic authentication](/docs/platform/auth/identified-clients#basic) and directly specify the `clientId` when instantiating the agent client. This identity appears as the [`clientId`](/docs/messages#properties) in all messages the agent publishes, allowing subscribers to identify the agent which published a message.
 
 <Code>
 ```javascript
@@ -681,7 +681,7 @@ channel.subscribe(message -> {
 </Code>
 
 <Aside data-type="note">
-Agents can also authenticate using [token authentication](/docs/auth/token), which is useful when agents run in environments where API keys cannot be accessed securely or when agents need [dynamic capabilities](/docs/auth/token#dynamic-channel-access-control).
+Agents can also authenticate using [token authentication](/docs/platform/auth/token), which is useful when agents run in environments where API keys cannot be accessed securely or when agents need [dynamic capabilities](/docs/platform/auth/token#dynamic-channel-access-control).
 </Aside>
 
 ## Adding roles and attributes <a id="roles-attributes"/>
@@ -690,7 +690,7 @@ Embed custom roles and attributes in messages to enable role-based access contro
 
 ### User claims <a id="user-claims"/>
 
-Use [authenticated claims for users](/docs/auth/capabilities#custom-restrictions-on-channels-) to embed custom claims in JWTs that represent user roles or attributes.
+Use [authenticated claims for users](/docs/platform/auth/capabilities#custom-restrictions-on-channels-) to embed custom claims in JWTs that represent user roles or attributes.
 
 Add claims with names matching the `ably.channel.*` pattern to your JWT to specify user claims for specific channels. Claims can be scoped to individual channels or to [namespaces](/docs/channels#namespaces) of channels. The most specific user claim matching the channel is automatically included under `extras.userClaim` in all messages the client publishes.
 
diff --git a/src/pages/docs/ai-transport/sessions-identity/online-status.mdx b/src/pages/docs/ai-transport/sessions-identity/online-status.mdx
index 72cd20186a..0be1b5bf46 100644
--- a/src/pages/docs/ai-transport/sessions-identity/online-status.mdx
+++ b/src/pages/docs/ai-transport/sessions-identity/online-status.mdx
@@ -26,7 +26,7 @@ For details on authenticating users and agents and setting the `clientId`, see [
 You have flexibility in when to enter presence. For example, an agent might choose to appear as online only while processing a specific task, or remain present for the duration of the entire session. Users typically enter presence when they connect to a session and remain present until they disconnect.
 
 <Aside data-type="note">
-Clients require the [`presence`](/docs/auth/capabilities) capability on the channel to participate in presence.
+Clients require the [`presence`](/docs/platform/auth/capabilities) capability on the channel to participate in presence.
 </Aside>
 
 For example, a user client can enter presence when joining a session:
@@ -98,7 +98,7 @@ channel.presence.enter(data);
 
 ### Going online from multiple devices <a id="multiple-devices"/>
 
-A single user can be present on a channel from multiple devices simultaneously. Ably tracks each connection separately using a unique [`connectionId`](/docs/connect#connection-ids), while maintaining the same [`clientId`](/docs/auth/identified-clients#assign) across all connections.
+A single user can be present on a channel from multiple devices simultaneously. Ably tracks each connection separately using a unique [`connectionId`](/docs/connect#connection-ids), while maintaining the same [`clientId`](/docs/platform/auth/identified-clients#assign) across all connections.
 
 When a user connects from multiple devices, each device enters presence independently. All connections share the same `clientId` but have different `connectionId` values.
 
@@ -360,7 +360,7 @@ AblyRealtime ably = new AblyRealtime(options);
 Participants in a session can query the current presence set or subscribe to presence events to see who else is online and react to changes in realtime. Users might want to see which agents are processing work, while agents might want to detect when specific users are offline to pause or cancel work.
 
 <Aside data-type="note">
-Clients require the `subscribe` [capability](/docs/auth/capabilities) on the channel to retrieve the presence set and subscribe to presence events.
+Clients require the `subscribe` [capability](/docs/platform/auth/capabilities) on the channel to retrieve the presence set and subscribe to presence events.
 </Aside>
 
 ### Retrieving current presence members <a id="get-members"/>
diff --git a/src/pages/docs/ai-transport/sessions-identity/push-notifications.mdx b/src/pages/docs/ai-transport/sessions-identity/push-notifications.mdx
index 4da9d08626..b906abac40 100644
--- a/src/pages/docs/ai-transport/sessions-identity/push-notifications.mdx
+++ b/src/pages/docs/ai-transport/sessions-identity/push-notifications.mdx
@@ -31,7 +31,7 @@ Push notification setup is platform-specific. See the following guides to config
 </Aside>
 
 <Aside data-type="note">
-To send push notifications to a specific user's devices rather than to channel subscribers, the agent's token requires the `push-admin` [capability](/docs/auth/capabilities). This enables direct publishing via the Push Admin API.
+To send push notifications to a specific user's devices rather than to channel subscribers, the agent's token requires the `push-admin` [capability](/docs/platform/auth/capabilities). This enables direct publishing via the Push Admin API.
 </Aside>
 
 ## Opt-in patterns <a id="opt-in"/>
diff --git a/src/pages/docs/ai-transport/sessions-identity/resuming-sessions.mdx b/src/pages/docs/ai-transport/sessions-identity/resuming-sessions.mdx
index 88d63c12fb..f308b8cad2 100644
--- a/src/pages/docs/ai-transport/sessions-identity/resuming-sessions.mdx
+++ b/src/pages/docs/ai-transport/sessions-identity/resuming-sessions.mdx
@@ -59,7 +59,7 @@ Ably provides access to channel message history, enabling agents to retrieve any
 When an agent resumes, it needs to retrieve messages published while it was offline. Use [channel history](/docs/storage-history/history) with the [`untilAttach` option](/docs/storage-history/history#continuous-history) to catch up on historical messages while preserving continuity with live message delivery.
 
 <Aside data-type="note">
-Clients require the [`history`](/docs/auth/capabilities) capability on the channel to retrieve message history.
+Clients require the [`history`](/docs/platform/auth/capabilities) capability on the channel to retrieve message history.
 </Aside>
 
 #### Persisted session state
diff --git a/src/pages/docs/ai-transport/token-streaming/message-per-response.mdx b/src/pages/docs/ai-transport/token-streaming/message-per-response.mdx
index b8e6ea6026..849a9a6f1f 100644
--- a/src/pages/docs/ai-transport/token-streaming/message-per-response.mdx
+++ b/src/pages/docs/ai-transport/token-streaming/message-per-response.mdx
@@ -41,7 +41,7 @@ To enable the channel rule:
 
 The examples on this page use the `ai:` namespace prefix, which assumes you have configured the rule for `ai`.
 
-Your token or API key needs the following [capabilities](/docs/auth/capabilities) on the channel:
+Your token or API key needs the following [capabilities](/docs/platform/auth/capabilities) on the channel:
 
 | Capability | Purpose |
 | --- | --- |
diff --git a/src/pages/docs/api/realtime-sdk.mdx b/src/pages/docs/api/realtime-sdk.mdx
index 3592550f6b..63fc007ee0 100644
--- a/src/pages/docs/api/realtime-sdk.mdx
+++ b/src/pages/docs/api/realtime-sdk.mdx
@@ -10,7 +10,7 @@ redirect_from:
 
 ## Constructor <a id="constructor" />
 
-The Ably Realtime library constructor is overloaded allowing it to be instantiated using a [`ClientOptions`](#client-options) object, or more simply using a string containing an [API key](/docs/auth/basic) or [Token](/docs/auth/token), as shown below:
+The Ably Realtime library constructor is overloaded allowing it to be instantiated using a [`ClientOptions`](#client-options) object, or more simply using a string containing an [API key](/docs/platform/auth/basic) or [Token](/docs/platform/auth/token), as shown below:
 
 <If lang="javascript,nodejs">
 
@@ -116,13 +116,13 @@ The Realtime constructor is used to instantiate the library. The Realtime librar
 
 ### Authentication <a id="authentication" />
 
-The Realtime library needs to have credentials to be able to authenticate with the Ably service. Ably supports both Basic and Token based authentication schemes. Read more on [authentication](/docs/auth).
+The Realtime library needs to have credentials to be able to authenticate with the Ably service. Ably supports both Basic and Token based authentication schemes. Read more on [authentication](/docs/platform/auth).
 
 #### Basic Authentication
 
 <If lang="javascript,nodejs,ruby,java,swift,objc,flutter,csharp">
 
-You can pass a full-length API key in as `ClientOptions#key` (or just straight into the constructor instead of a `ClientOptions` instance), as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use [Basic authentication](/docs/auth/basic), or if you want to be able to [request Ably Tokens](/docs/auth/token) without needing to defer to a separate entity to sign [Ably TokenRequests](/docs/api/realtime-sdk/authentication#token-request). Note that initializing the library with a `key` does not necessarily mean that the library will use Basic auth; it is also able to create and sign Ably [TokenRequests](/docs/api/realtime-sdk/authentication#token-request), and can use token authentication for itself if it needs to or if [`ClientOptions#useTokenAuth`](#client-options) is enabled.
+You can pass a full-length API key in as `ClientOptions#key` (or just straight into the constructor instead of a `ClientOptions` instance), as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use [Basic authentication](/docs/platform/auth/basic), or if you want to be able to [request Ably Tokens](/docs/platform/auth/token) without needing to defer to a separate entity to sign [Ably TokenRequests](/docs/api/realtime-sdk/authentication#token-request). Note that initializing the library with a `key` does not necessarily mean that the library will use Basic auth; it is also able to create and sign Ably [TokenRequests](/docs/api/realtime-sdk/authentication#token-request), and can use token authentication for itself if it needs to or if [`ClientOptions#useTokenAuth`](#client-options) is enabled.
 
 </If>
 
@@ -146,7 +146,7 @@ The [`ClientOptions#token`](#client-options) option takes a `token` string or [t
 
 </If>
 
-Read more on [authentication](/docs/auth).
+Read more on [authentication](/docs/platform/auth).
 
 <If lang="objc,swift">
 
@@ -844,17 +844,17 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 
 | Property | Description |
 |----------|-------------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic)<br />**Type:** `String` |
-| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))` which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic)<br />**Type:** `String` |
+| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))` which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `Callable` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server<br />**Type:** `String` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />**Type:** `String`<br />**Default:** `GET` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. <If lang="javascript">If the `authHeaders` object contains an `authorization` key, then `withCredentials` will be set on the xhr request</If><br />**Type:** `Object` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response<br />**Type:** `Object` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Type:** `Boolean`<br />**Default:** true |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients)<br />**Type:** `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients)<br />**Type:** `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** null |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** null |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Type:** `Boolean`<br />**Default:** true |
@@ -869,7 +869,7 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 | transports | An optional array of transports to use, in descending order of preference. <If lang="javascript">In the browser environment the available transports are: `web_socket`, `xhr_polling`</If><If lang="nodejs">The transports available in the Node.js client library are: `web_socket`, `xhr_polling`, `comet`</If><br />**Type:** `String[]` |
 | recover | <If lang="javascript">This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the Realtime library. This might typically be used by clients of the browser library to ensure connection state can be preserved when the user refreshes the page. A recovery key string can be explicitly provided, or alternatively if a callback function is provided, the client library will automatically persist the recovery key between page reloads and call the callback when the connection is recoverable. The callback is then responsible for confirming whether the connection should be recovered or not. See [connection state recovery](/docs/connect/states) for further information<br />**Type:** `String`, `Callable`</If><If lang="nodejs">This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the library by providing that connection's [`recoveryKey`](/docs/api/realtime-sdk/connection#recovery-key). This might typically be used by clients of an app to ensure connection state can be preserved following a reload. See [connection state recovery](/docs/connect/states) for further information and example code<br />**Type:** `String`</If> |
 | closeOnUnload | <If lang="javascript">When true, the client library will automatically send a close request to Ably whenever the `window beforeunload` event fires. By enabling this option, the close request sent to Ably ensures the connection state will not be retained and all channels associated with the connection will be detached. This is commonly used by developers who want presence leave events to fire immediately i.e. if a user navigates to another page or closes their browser, then enabling this option will result in the presence member leaving immediately. Without this option or an explicit call to the [`close`](/docs/api/realtime-sdk/connection#close) method of the [`Connection object`](/docs/api/realtime-sdk/connection), Ably expects that the abruptly disconnected connection could later be recovered and therefore does not immediately remove the user from presence. Instead, to avoid "twitchy" presence behavior an abruptly disconnected client is removed from channels in which they are present after 15 seconds, and the connection state is retained for two minutes<br />**Type:** `Boolean`<br />**Default:** true</If> |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
 | defaultTokenParams | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests<br />**Type:** [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | disconnectedRetryTimeout | When the connection enters the `DISCONNECTED` state, after this delay in milliseconds, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Type:** `Integer`<br />**Default:** 15,000ms |
 | suspendedRetryTimeout | When the connection enters the `SUSPENDED` state, after this delay in milliseconds, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Type:** `Integer`<br />**Default:** 30,000ms |
@@ -881,17 +881,17 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 
 | Property | Description |
 |----------|-------------|
-| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic)<br />**Type:** `String` |
-| Token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `Token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
-| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `Func<TokenParams, Task<object>>` |
+| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic)<br />**Type:** `String` |
+| Token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `Token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
+| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `Func<TokenParams, Task<object>>` |
 | AuthUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server<br />**Type:** `Uri` |
 | AuthMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />**Type:** `HttpMethod`<br />**Default:** `GET` |
 | AuthHeaders | A set of key value pair headers to be added to any request made to the `AuthUrl`. Useful when an application requires these to be added to validate the request or implement the response<br />**Type:** `Dictionary<string, string>` |
 | AuthParams | A set of key value pair params to be added to any request made to the `AuthUrl`. When the `AuthMethod` is `GET`, query params are added to the URL, whereas when `AuthMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response<br />**Type:** `Dictionary<string, string>` |
-| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `TokenDetails` |
+| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `TokenDetails` |
 | Tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Type:** `Boolean`<br />**Default:** true |
-| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `ClientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `ClientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `ClientId` specified here conflicts with the `ClientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients)<br />**Type:** `String` |
-| UseTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
+| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `ClientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `ClientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `ClientId` specified here conflicts with the `ClientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients)<br />**Type:** `String` |
+| UseTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
 | Endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** null |
 | Environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** null |
 | IdempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Type:** `Boolean`<br />**Default:** true |
@@ -904,7 +904,7 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 | EchoMessages | If false, prevents messages originating from this connection being echoed back on the same connection<br />**Type:** `Boolean`<br />**Default:** true |
 | AutoConnect | By default as soon as the client library is instantiated it will connect to Ably. You can optionally set this to false and explicitly connect to Ably when require using the [`connect`](/docs/api/realtime-sdk/connection#connect) method<br />**Type:** `Boolean`<br />**Default:** true |
 | Recover | This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the library by providing that connection's [`recoveryKey`](/docs/api/realtime-sdk/connection#recovery-key). This might typically be used by clients of an app to ensure connection state can be preserved following a reload. See [connection state recovery](/docs/connect/states) for further information and example code<br />**Type:** `String` |
-| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
+| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
 | DefaultTokenParams | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests<br />**Type:** [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | DisconnectedRetryTimeout | When the connection enters the `DISCONNECTED` state, after this delay in milliseconds, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Type:** `Integer`<br />**Default:** 15,000ms |
 | SuspendedRetryTimeout | When the connection enters the `SUSPENDED` state, after this delay in milliseconds, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Type:** `Integer`<br />**Default:** 30,000ms |
@@ -915,17 +915,17 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 
 | Property | Description |
 |----------|-------------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic)<br />**Type:** `String` |
-| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A `TokenCallback` instance which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `TokenCallback` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic)<br />**Type:** `String` |
+| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A `TokenCallback` instance which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `TokenCallback` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server<br />**Type:** `String` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />**Type:** `String`<br />**Default:** `GET` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response<br />**Type:** `Param[]` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response<br />**Type:** `Param[]` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Type:** `Boolean`<br />**Default:** true |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients)<br />**Type:** `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients)<br />**Type:** `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** Null |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** Null |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Type:** `Boolean`<br />**Default:** true |
@@ -938,7 +938,7 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 | echoMessages | If false, prevents messages originating from this connection being echoed back on the same connection<br />**Type:** `Boolean`<br />**Default:** true |
 | autoConnect | By default as soon as the client library is instantiated it will connect to Ably. You can optionally set this to false and explicitly connect to Ably when require using the [`connect`](/docs/api/realtime-sdk/connection#connect) method<br />**Type:** `Boolean`<br />**Default:** true |
 | recover | This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the library by providing that connection's [`recoveryKey`](/docs/api/realtime-sdk/connection#recovery-key). This might typically be used by clients of an app to ensure connection state can be preserved following a reload. See [connection state recovery](/docs/connect/states) for further information and example code<br />**Type:** `String` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
 | defaultTokenParams | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests<br />**Type:** [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | disconnectedRetryTimeout | When the connection enters the `DISCONNECTED` state, after this delay in milliseconds, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Type:** `Integer`<br />**Default:** 15,000ms |
 | suspendedRetryTimeout | When the connection enters the `SUSPENDED` state, after this delay in milliseconds, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Type:** `Integer`<br />**Default:** 30,000ms |
@@ -949,17 +949,17 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 
 | Property | Description |
 |----------|-------------|
-| :key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic)<br />**Type:** `String` |
-| :token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the :token property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as :auth_url or :auth_callback. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
-| :auth_callback | A proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter) which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `Proc` |
+| :key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic)<br />**Type:** `String` |
+| :token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the :token property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as :auth_url or :auth_callback. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
+| :auth_callback | A proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter) which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `Proc` |
 | :auth_url | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server<br />**Type:** String |
 | :auth_method | The HTTP verb to use for the request, either `:get` or `:post`<br />**Type:** `Symbol`<br />**Default:** `:get` |
 | :auth_headers | A set of key value pair headers to be added to any request made to the :auth_url. Useful when an application requires these to be added to validate the request or implement the response<br />**Type:** `Hash` |
 | :auth_params | A set of key value pair params to be added to any request made to the :auth_url. When the :auth_method is `GET`, query params are added to the URL, whereas when :auth_method is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response<br />**Type:** `Hash` |
-| :token_details | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as :auth_url or :auth_callback. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `TokenDetails` |
+| :token_details | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as :auth_url or :auth_callback. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `TokenDetails` |
 | :tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Type:** `Boolean`<br />**Default:** true |
-| :client_id | A client ID, used for identifying this client when publishing messages or for presence purposes. The `client_id` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `client_id` may also be implicit in a token used to instantiate the library; an error will be raised if a `client_id` specified here conflicts with the `client_id` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients)<br />**Type:** `String` |
-| :use_token_auth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `client_id` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
+| :client_id | A client ID, used for identifying this client when publishing messages or for presence purposes. The `client_id` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `client_id` may also be implicit in a token used to instantiate the library; an error will be raised if a `client_id` specified here conflicts with the `client_id` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients)<br />**Type:** `String` |
+| :use_token_auth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `client_id` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
 | :endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** nil |
 | :environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** nil |
 | :idempotent_rest_publishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Type:** `Boolean`<br />**Default:** true |
@@ -972,7 +972,7 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 | :echo_messages | If false, prevents messages originating from this connection being echoed back on the same connection<br />**Type:** `Boolean`<br />**Default:** true |
 | :auto_connect | By default as soon as the client library is instantiated it will connect to Ably. You can optionally set this to false and explicitly connect to Ably when require using the [`connect`](/docs/api/realtime-sdk/connection#connect) method<br />**Type:** `Boolean`<br />**Default:** true |
 | :recover | This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the library by providing that connection's [`recovery_key`](/docs/api/realtime-sdk/connection#recovery-key). This might typically be used by clients of an app to ensure connection state can be preserved following a reload. See [connection state recovery](/docs/connect/states) for further information and example code<br />**Type:** `String` |
-| :query_time | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
+| :query_time | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
 | :default_token_params | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests<br />**Type:** [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | :disconnected_retry_timeout | When the connection enters the `DISCONNECTED` state, after this delay in seconds, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Type:** Integer<br />**Default:** 15s |
 | :suspended_retry_timeout | When the connection enters the `SUSPENDED` state, after this delay in seconds, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Type:** Integer<br />**Default:** 30s |
@@ -983,17 +983,17 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 
 | Property | Description |
 |----------|-------------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic)<br />**Type:** `String` |
-| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic)<br />**Type:** `String` |
+| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `Callable` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server<br />**Type:** `NSURL` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />**Type:** `String`<br />**Default:** `GET` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response<br />**Type:** `Object` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response<br />**Type:** `[NSURLQueryItem]/Array<NSURLQueryItem>` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Type:** `Boolean`<br />**Default:** true |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients)<br />**Type:** `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients)<br />**Type:** `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** nil |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** nil |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Type:** `Boolean`<br />**Default:** true |
@@ -1007,7 +1007,7 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 | echoMessages | If false, prevents messages originating from this connection being echoed back on the same connection<br />**Type:** `Boolean`<br />**Default:** true |
 | autoConnect | By default as soon as the client library is instantiated it will connect to Ably. You can optionally set this to false and explicitly connect to Ably when require using the [`connect`](/docs/api/realtime-sdk/connection#connect) method<br />**Type:** `Boolean`<br />**Default:** true |
 | recover | This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the library by providing that connection's [`recoveryKey`](/docs/api/realtime-sdk/connection#recovery-key). This might typically be used by clients of an app to ensure connection state can be preserved following a reload. See [connection state recovery](/docs/connect/states) for further information and example code<br />**Type:** `String` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
 | defaultTokenParams | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests<br />**Type:** [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | disconnectedRetryTimeout | When the connection enters the `DISCONNECTED` state, after this delay as a `NSTimeInterval`, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Type:** `NSTimeInterval`<br />**Default:** 15,000ms |
 | suspendedRetryTimeout | When the connection enters the `SUSPENDED` state, after this delay as a `NSTimeInterval`, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Type:** `NSTimeInterval`<br />**Default:** 30,000ms |
@@ -1018,17 +1018,17 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 
 | Property | Description |
 |----------|-------------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic)<br />**Type:** `String` |
-| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic)<br />**Type:** `String` |
+| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `Callable` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server<br />**Type:** `NSURL` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />**Type:** `String`<br />**Default:** `GET` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response<br />**Type:** `Object` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response<br />**Type:** `NSArray<NSURLQueryItem *>` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Type:** `Boolean`<br />**Default:** true |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients)<br />**Type:** `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients)<br />**Type:** `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** nil |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** nil |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Type:** `Boolean`<br />**Default:** true |
@@ -1042,7 +1042,7 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 | echoMessages | If false, prevents messages originating from this connection being echoed back on the same connection<br />**Type:** `Boolean`<br />**Default:** true |
 | autoConnect | By default as soon as the client library is instantiated it will connect to Ably. You can optionally set this to false and explicitly connect to Ably when require using the [`connect`](/docs/api/realtime-sdk/connection#connect) method<br />**Type:** `Boolean`<br />**Default:** true |
 | recover | This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the library by providing that connection's [`recoveryKey`](/docs/api/realtime-sdk/connection#recovery-key). This might typically be used by clients of an app to ensure connection state can be preserved following a reload. See [connection state recovery](/docs/connect/states) for further information and example code<br />**Type:** `String` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
 | defaultTokenParams | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests<br />**Type:** [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | disconnectedRetryTimeout | When the connection enters the `DISCONNECTED` state, after this delay as a `NSTimeInterval`, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Type:** `NSTimeInterval`<br />**Default:** 15,000ms |
 | suspendedRetryTimeout | When the connection enters the `SUSPENDED` state, after this delay as a `NSTimeInterval`, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Type:** `NSTimeInterval`<br />**Default:** 30,000ms |
@@ -1053,17 +1053,17 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 
 | Property | Description |
 |----------|-------------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic)<br />**Type:** `String` |
-| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic)<br />**Type:** `String` |
+| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls<br />**Type:** `Callable` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server<br />**Type:** `String` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />**Type:** `String`<br />**Default:** `GET` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response<br />**Type:** `Map<String, String>` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response<br />**Type:** `Map<String, String>` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token)<br />**Type:** `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token)<br />**Type:** `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Type:** `Boolean`<br />**Default:** true |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients)<br />**Type:** `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients)<br />**Type:** `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Type:** `Boolean`<br />**Default:** false |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** null |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Type:** `String`<br />**Default:** null |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Type:** `Boolean`<br />**Default:** true |
@@ -1073,7 +1073,7 @@ Returns a promise. On success, the promise is fulfilled with a [BatchResult](#ba
 | queueMessages | If false, this disables the default behavior whereby the library queues messages on a connection in the disconnected or connecting states. The default behavior allows applications to submit messages immediately upon instancing the library without having to wait for the connection to be established. Applications may use this option to disable queueing if they wish to have application-level control over the queueing under those conditions<br />**Type:** `Boolean`<br />**Default:** true |
 | echoMessages | If false, prevents messages originating from this connection being echoed back on the same connection<br />**Type:** `Boolean`<br />**Default:** true |
 | autoConnect | By default as soon as the client library is instantiated it will connect to Ably. You can optionally set this to false and explicitly connect to Ably when require using the [`connect`](/docs/api/realtime-sdk/connection#connect) method<br />**Type:** `Boolean`<br />**Default:** true |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Type:** `Boolean`<br />**Default:** false |
 | defaultTokenParams | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests<br />**Type:** [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | disconnectedRetryTimeout | When the connection enters the `DISCONNECTED` state, after this delay in milliseconds, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Type:** `Integer`<br />**Default:** 15,000ms |
 | suspendedRetryTimeout | When the connection enters the `SUSPENDED` state, after this delay in milliseconds, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Type:** `Integer`<br />**Default:** 30,000ms |
diff --git a/src/pages/docs/api/realtime-sdk/authentication.mdx b/src/pages/docs/api/realtime-sdk/authentication.mdx
index 23cdfb58e5..d024eff3e0 100644
--- a/src/pages/docs/api/realtime-sdk/authentication.mdx
+++ b/src/pages/docs/api/realtime-sdk/authentication.mdx
@@ -29,7 +29,7 @@ In the documentation, references to Ably-compatible tokens typically refer eithe
 
 ## Auth object <a id="#auth-object" />
 
-The principal use-case for the `Auth` object is to create Ably [`TokenRequest`](#token-request) objects with [createTokenRequest](#create-token-request) or obtain [Ably Tokens](#token-details) from Ably with [requestToken](#request-token), and then issue them to other "less trusted" clients. Typically, your servers should be the only devices to have a [private API key](/docs/auth#api-key), and this private API key is used to securely sign Ably [`TokenRequest`](#token-request) objects or request [Ably Tokens](#token-details) from Ably. Clients are then issued with these short-lived [Ably Tokens](#token-details) or Ably [`TokenRequest`](#token-request) objects, and the libraries can then use these to authenticate with Ably. If you adopt this model, your private API key is never shared with clients directly.
+The principal use-case for the `Auth` object is to create Ably [`TokenRequest`](#token-request) objects with [createTokenRequest](#create-token-request) or obtain [Ably Tokens](#token-details) from Ably with [requestToken](#request-token), and then issue them to other "less trusted" clients. Typically, your servers should be the only devices to have a [private API key](/docs/platform/auth#api-key), and this private API key is used to securely sign Ably [`TokenRequest`](#token-request) objects or request [Ably Tokens](#token-details) from Ably. Clients are then issued with these short-lived [Ably Tokens](#token-details) or Ably [`TokenRequest`](#token-request) objects, and the libraries can then use these to authenticate with Ably. If you adopt this model, your private API key is never shared with clients directly.
 
 A subsidiary use-case for the `Auth` object is to preemptively trigger renewal of a token or to acquire a new token with a revised set of capabilities by explicitly calling <If lang="javascript,nodejs,java,objc,ruby,swift">[`authorize`](#authorize)</If><If lang="csharp">[`Authorize`](#authorize)</If>.
 
@@ -41,7 +41,7 @@ The <If lang="objc,swift">`ART`</If>`Auth` object exposes the following public <
 
 ### <If lang="javascript,nodejs,java,objc,swift">clientId</If><If lang="ruby">client_id</If><If lang="csharp">ClientId</If> <a id="#client-id" />
 
-The client ID string, if any, configured for this client connection. See [identified clients](/docs/auth/identified-clients) for more information on trusted client identifiers.
+The client ID string, if any, configured for this client connection. See [identified clients](/docs/platform/auth/identified-clients) for more information on trusted client identifiers.
 
 ## <If lang="javascript,nodejs">Auth Methods</If><If lang="java">io.ably.lib.rest.Auth Methods</If><If lang="csharp">IO.Ably.AblyAuth Methods</If><If lang="ruby">Ably::Auth Methods</If><If lang="objc,swift">ARTAuth Methods</If> <a id="#methods" />
 
@@ -299,11 +299,11 @@ client.auth.authorize(tokenParams, options: nil) { tokenDetails, error in
 
 </If>
 
-Creates and signs an Ably [`TokenRequest`](#request-token) based on the specified (or if none specified, the client library stored) <If lang="ruby">`token_params` and `auth_options`</If><If lang="javascript,nodejs,java,csharp,objc,swift">`tokenParams` and `authOptions`</If>. Note this can only be used when the [API `key`](/docs/auth#api-key) value is available locally. Otherwise, the Ably [`TokenRequest`](#request-token) must be obtained from the key owner. Use this to generate Ably [`TokenRequests`](#request-token) in order to implement an [Ably Token](#token-details) request callback for use by other clients.
+Creates and signs an Ably [`TokenRequest`](#request-token) based on the specified (or if none specified, the client library stored) <If lang="ruby">`token_params` and `auth_options`</If><If lang="javascript,nodejs,java,csharp,objc,swift">`tokenParams` and `authOptions`</If>. Note this can only be used when the [API `key`](/docs/platform/auth#api-key) value is available locally. Otherwise, the Ably [`TokenRequest`](#request-token) must be obtained from the key owner. Use this to generate Ably [`TokenRequests`](#request-token) in order to implement an [Ably Token](#token-details) request callback for use by other clients.
 
 Both <If lang="ruby">`auth_options` and `token_params`</If><If lang="javascript,nodejs,java,csharp,objc,swift">`authOptions` and `tokenParams`</If> are optional. When omitted or `null`, the default token parameters and authentication options for the client library are used, as specified in the `ClientOptions` when the client library was instantiated, or later updated with an explicit <If lang="javascript,nodejs,java,objc,swift,ruby">[`authorize`](#authorize)</If><If lang="csharp">[`Authorize`](#authorize)</If> request.  Values passed in will be used instead of (rather than being merged with) the default values.
 
-To understand why an Ably [`TokenRequest`](#request-token) may be issued to clients in favor of a token, see [Token Authentication explained](/docs/auth/token).
+To understand why an Ably [`TokenRequest`](#request-token) may be issued to clients in favor of a token, see [Token Authentication explained](/docs/platform/auth/token).
 
 #### Parameters
 
@@ -516,7 +516,7 @@ Calls the [`requestToken` REST API endpoint](/docs/api/rest-api#request-token) t
 
 Both <If lang="ruby">`auth_options` and `token_params`</If><If lang="javascript,nodejs,java,csharp,objc,swift">`authOptions` and `tokenParams`</If> are optional. When omitted or `null`, the default token parameters and authentication options for the client library are used, as specified in the `ClientOptions` when the client library was instantiated, or later updated with an explicit <If lang="javascript,nodejs,java,objc,swift,ruby">[`authorize`](#authorize)</If><If lang="csharp">[`Authorize`](#authorize)</If> request.  Values passed in will be used instead of (rather than being merged with) the default values.
 
-To understand why an Ably [`TokenRequest`](#request-token) may be issued to clients in favor of a token, see [Token Authentication explained](/docs/auth/token).
+To understand why an Ably [`TokenRequest`](#request-token) may be issued to clients in favor of a token, see [Token Authentication explained](/docs/platform/auth/token).
 
 #### Parameters
 
@@ -710,7 +710,7 @@ client.auth.requestToken(tokenParams, withOptions: : nil) { tokenDetails, error
 
 Calls the [`revokeTokens` REST API endpoint](/docs/api/rest-api#revoke-tokens) to revoke tokens specified by the provided array of [TokenRevocationTargetSpecifier](#token-revocation-target-specifier).
 
-Only tokens issued by an API key that had revocable tokens enabled before the token was issued can be revoked. See the [token revocation docs](/docs/auth/revocation) for more information.
+Only tokens issued by an API key that had revocable tokens enabled before the token was issued can be revoked. See the [token revocation docs](/docs/platform/auth/revocation) for more information.
 
 #### Parameters
 
@@ -767,25 +767,25 @@ try {
 
 <If lang="javascript,nodejs">
 
-`AuthOptions` is a plain JavaScript object and is used when making [authentication](/docs/auth) requests. If passed in, an `authOptions` object will be used instead of (as opposed to supplementing or being merged with) the default values given when the library was instantiated. The following attributes are supported:
+`AuthOptions` is a plain JavaScript object and is used when making [authentication](/docs/platform/auth) requests. If passed in, an `authOptions` object will be used instead of (as opposed to supplementing or being merged with) the default values given when the library was instantiated. The following attributes are supported:
 
 </If>
 
 <If lang="ruby">
 
-`AuthOptions` is a Hash object and is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following key symbol values can be added to the Hash:
+`AuthOptions` is a Hash object and is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following key symbol values can be added to the Hash:
 
 </If>
 
 <If lang="swift,objc">
 
-`ARTAuthOptions` is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated.
+`ARTAuthOptions` is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated.
 
 </If>
 
 <If lang="java">
 
-`AuthOptions` is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated.
+`AuthOptions` is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated.
 
 </If>
 
@@ -793,15 +793,15 @@ try {
 
 | Property | Description | Type |
 |----------|-------------|------|
-| <If lang="javascript,nodejs,java,objc,swift">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="ruby">:auth_callback</If> | A <If lang="objc,swift">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) ; a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,objc,swift">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If><If lang="csharp">`Func<TokenParams, Task<object>>`</If> |
+| <If lang="javascript,nodejs,java,objc,swift">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="ruby">:auth_callback</If> | A <If lang="objc,swift">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) ; a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,objc,swift">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If><If lang="csharp">`Func<TokenParams, Task<object>>`</If> |
 | <If lang="javascript,nodejs,java,objc,swift">authUrl</If><If lang="csharp,go">AuthUrl</If><If lang="ruby">:auth_url</If> | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) ; a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | <If lang="javascript,nodejs,java">`String`</If><If lang="csharp">`Uri`</If><If lang="swift,objc">`NSURL`</If> |
 | <If lang="javascript,nodejs,java,objc,swift">authMethod</If><If lang="csharp">AuthMethod</If><If lang="ruby">:auth_method</If> | _<If lang="javascript,nodejs,java,objc,swift">`GET`</If><If lang="ruby">`:get`</If>_ The HTTP verb to use for the request, either <If lang="javascript,nodejs,java,objc,swift">`GET`</If><If lang="ruby">`:get`</If> or <If lang="javascript,nodejs,java,objc,swift">`POST`</If><If lang="ruby">`:post`</If> | <If lang="javascript,nodejs,java,objc,swift">`String`</If><If lang="ruby">`Symbol`</If><If lang="csharp">`HttpMethod`</If> |
 | <If lang="javascript,nodejs,objc,java,swift">authHeaders</If><If lang="csharp,go">AuthHeaders</If><If lang="ruby">:auth_headers</If> | A set of key value pair headers to be added to any request made to the <If lang="nodejs,objc,swift,javascript">`authUrl`</If><If lang="csharp">`AuthUrl`</If>. Useful when an application requires these to be added to validate the request or implement the response. <If lang="javascript,nodejs">If the `authHeaders` object contains an `authorization` key, then `withCredentials` will be set on the xhr request.</If> | <If lang="javascript,nodejs,objc,swift">`Object`</If><If lang="ruby">`Hash`</If><If lang="java">`Param []`</If><If lang="csharp">`Dictionary<string, string>`</If> |
 | <If lang="javascript,nodejs,java,objc,swift">authParams</If><If lang="csharp">AuthParams</If><If lang="ruby">:auth_params</If> | A set of key value pair params to be added to any request made to the <If lang="javascript,nodejs">`authUrl`</If><If lang="csharp">`AuthUrl`</If>. When the <If lang="javascript,nodejs">`authMethod`</If><If lang="csharp">`AuthMethod`</If> is `GET`, query params are added to the URL, whereas when <If lang="javascript,nodejs">`authMethod`</If><If lang="csharpo">`AuthMethod`</If> is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | <If lang="javascript,nodejs">`Object`</If><If lang="ruby">`Hash`</If><If lang="java">`Param[]`</If><If lang="csharp">`Dictionary<string, string>`</If><If lang="objc">`NSArray<NSURLQueryItem *>`</If><If lang="swift">`[NSURLQueryItem]/Array<NSURLQueryItem>`</If> |
-| <If lang="javascript,nodejs,java,objc,swift">tokenDetails</If><If lang="csharp,go">TokenDetails</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,swift">`authUrl`</If><If lang="csharp">`AuthUrl`</If><If lang="ruby">`:auth_url`</If> or <If lang="javascript,nodejs,java,objc,swift">`authCallback`</If><If lang="csharp">AuthCallback</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
-| <If lang="javascript,nodejs,java,objc,swift">key</If><If lang="csharp">Key</If><If lang="ruby">:key</If> | Optionally the [API key](/docs/auth#api-key) to use can be specified as a full key string; if not, the API key passed into [`ClientOptions`](#client-options) when instancing the Realtime or REST library is used | `String` |
-| <If lang="javascript,nodejs,java,objc,swift">queryTime</If><If lang="csharp,go">QueryTime</If><If lang="ruby">:query_time</If> | _false_ If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/auth/token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd) . The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. | `Boolean` |
-| <If lang="javascript,nodejs,java,objc,swift">token</If><If lang="csharp,go">Token</If><If lang="ruby">:token</If> | An authentication token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,java,objc,swift">`token`</If><If lang="csharp,go">`Token`</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,swift">`authUrl`</If><If lang="csharp">AuthUrl</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> or <If lang="javascript,nodejs,java,objc,swift">authCallback</If><If lang="csharp">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If>. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| <If lang="javascript,nodejs,java,objc,swift">tokenDetails</If><If lang="csharp,go">TokenDetails</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,swift">`authUrl`</If><If lang="csharp">`AuthUrl`</If><If lang="ruby">`:auth_url`</If> or <If lang="javascript,nodejs,java,objc,swift">`authCallback`</If><If lang="csharp">AuthCallback</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
+| <If lang="javascript,nodejs,java,objc,swift">key</If><If lang="csharp">Key</If><If lang="ruby">:key</If> | Optionally the [API key](/docs/platform/auth#api-key) to use can be specified as a full key string; if not, the API key passed into [`ClientOptions`](#client-options) when instancing the Realtime or REST library is used | `String` |
+| <If lang="javascript,nodejs,java,objc,swift">queryTime</If><If lang="csharp,go">QueryTime</If><If lang="ruby">:query_time</If> | _false_ If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/platform/auth/token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd) . The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. | `Boolean` |
+| <If lang="javascript,nodejs,java,objc,swift">token</If><If lang="csharp,go">Token</If><If lang="ruby">:token</If> | An authentication token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,java,objc,swift">`token`</If><If lang="csharp,go">`Token`</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,swift">`authUrl`</If><If lang="csharp">AuthUrl</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> or <If lang="javascript,nodejs,java,objc,swift">authCallback</If><If lang="csharp">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If>. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
 
 ### <If lang="javascript,nodejs">TokenDetails Object</If><If lang="objc,swift">ARTTokenDetails</If><If lang="java">io.ably.lib.types.TokenDetails</If><If lang="ruby">Ably::Models::TokenDetails</If><If lang="csharp">IO.Ably.TokenDetails</If> <a id="#token-details" />
 
@@ -814,8 +814,8 @@ try {
 | <If lang="javascript,nodejs,java,objc,swift,ruby">token</If><If lang="csharp">Token</If> | The [Ably Token](/docs/api/realtime-sdk/authentication#token-details) itself. A typical [Ably Token](/docs/api/realtime-sdk/authentication#token-details) string may appear like `{{TOKEN}}` | `String` |
 | <If lang="javascript,nodejs,java,objc,swift,ruby">expires</If><If lang="csharp">Expires</If> | <If lang="javascript,nodejs,java">The time (in milliseconds since the epoch)</If><If lang="ruby,objc,swift">The time</If> at which this token expires | <If lang="javascript,nodejs">`Integer`</If><If lang="java">`Long Integer`</If><If lang="csharp">`DateTimeOffset`</If><If lang="ruby">`Time`</If><If lang="objc,swift">`NSDate`</If> |
 | <If lang="javascript,nodejs,java,objc,swift,ruby">issued</If><If lang="csharp">Issued</If> | <If lang="javascript,nodejs,java">The time (in milliseconds since the epoch)</If><If lang="ruby,objc,swift">The time</If> at which this token was issued | <If lang="javascript,nodejs">`Integer`</If><If lang="java">`Long Integer`</If><If lang="csharp">`DateTimeOffset`</If><If lang="ruby">`Time`</If><If lang="objc,swift">`NSDate`</If> |
-| <If lang="javascript,nodejs,java,objc,swift,ruby">capability</If><If lang="csharp">Capability</If> | The capability associated with this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The capability is a a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/auth/capabilities) | <If lang="javascript,nodejs,java,objc,swift,ruby">`String`</If><If lang="csharp">`Capability`</If> |
-| <If lang="javascript,nodejs,java,objc,swift,flutter,php">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> | The client ID, if any, bound to this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If a client ID is included, then the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) authenticates its bearer as that client ID, and the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) may only be used to perform operations on behalf of that client ID. The client is then considered to be an [identified client](/docs/auth/identified-clients) | `String` |
+| <If lang="javascript,nodejs,java,objc,swift,ruby">capability</If><If lang="csharp">Capability</If> | The capability associated with this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The capability is a a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/platform/auth/capabilities) | <If lang="javascript,nodejs,java,objc,swift,ruby">`String`</If><If lang="csharp">`Capability`</If> |
+| <If lang="javascript,nodejs,java,objc,swift,flutter,php">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> | The client ID, if any, bound to this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If a client ID is included, then the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) authenticates its bearer as that client ID, and the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) may only be used to perform operations on behalf of that client ID. The client is then considered to be an [identified client](/docs/platform/auth/identified-clients) | `String` |
 
 <If lang="ruby">
 
@@ -868,25 +868,25 @@ A [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object
 
 <If lang="javascript,nodejs">
 
-`TokenParams` is a plain JavaScript object and is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following attributes can be defined on the object:
+`TokenParams` is a plain JavaScript object and is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following attributes can be defined on the object:
 
 </If>
 
 <If lang="ruby">
 
-`TokenParams` is a Hash object and is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following key symbol values can be added to the Hash:
+`TokenParams` is a Hash object and is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following key symbol values can be added to the Hash:
 
 </If>
 
 <If lang="java,csharp">
 
-`TokenParams` is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
+`TokenParams` is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
 
 </If>
 
 <If lang="objc,swift">
 
-`ARTTokenParams` is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
+`ARTTokenParams` is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
 
 </If>
 
@@ -894,8 +894,8 @@ A [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object
 
 | Property | Description | Type |
 |----------|-------------|------|
-| <If lang="javascript,nodejs,java,objc,swift">capability</If><If lang="csharp,go">Capability</If><If lang="ruby">:capability</If> | JSON stringified capability of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) request is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. [Find our more about how to use capabilities to manage access privileges for clients](/docs/auth/capabilities). | <If lang="javascript,nodejs,java,objc,swift">`String`</If><If lang="csharp">`Capability`</If> |
-| <If lang="javascript,nodejs,java,objc,swift">clientId</If><If lang="csharp,go">ClientId</If><If lang="python">client_id</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,java,objc,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,java,objc,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,java,objc,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> specified here conflicts with the <If lang="javascript,nodejs,java,objc,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
+| <If lang="javascript,nodejs,java,objc,swift">capability</If><If lang="csharp,go">Capability</If><If lang="ruby">:capability</If> | JSON stringified capability of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) request is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. [Find our more about how to use capabilities to manage access privileges for clients](/docs/platform/auth/capabilities). | <If lang="javascript,nodejs,java,objc,swift">`String`</If><If lang="csharp">`Capability`</If> |
+| <If lang="javascript,nodejs,java,objc,swift">clientId</If><If lang="csharp,go">ClientId</If><If lang="python">client_id</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,java,objc,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,java,objc,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,java,objc,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> specified here conflicts with the <If lang="javascript,nodejs,java,objc,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
 | <If lang="javascript,nodejs,java,objc,swift">nonce</If><If lang="csharp,go">Nonce</If><If lang="ruby">:nonce</If> | An optional opaque nonce string of at least 16 characters to ensure uniqueness of this request. Any subsequent request using the same nonce will be rejected. | `String` |
 | <If lang="javascript,nodejs,java,objc,swift">timestamp</If><If lang="csharp">Timestamp</If><If lang="ruby">:timestamp</If> | <If lang="javascript,nodejs,java">The timestamp (in milliseconds since the epoch)</If><If lang="ruby,objc,swift,csharp">The timestamp</If> of this request. `timestamp`, in conjunction with the `nonce`, is used to prevent requests for [Ably Token](/docs/api/realtime-sdk/authentication#token-details) from being replayed. | <If lang="javascript,nodejs">`Integer`</If><If lang="java">`Long Integer`</If><If lang="ruby">`Time`</If><If lang="objc,swift">`NSDate`</If><If lang="csharp">`DateTimeOffset`</If><If lang="flutter">`DateTime`</If> |
 | <If lang="javascript,nodejs,java,objc,swift">ttl</If><If lang="csharp">Ttl</If><If lang="ruby">:ttl</If> | Requested time to live for the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) being created <If lang="javascript,nodejs,java">in milliseconds</If><If lang="ruby">in seconds</If><If lang="objc,swift">as a `NSTimeInterval`</If><If lang="csharp">as a `TimeSpan`.</If> When omitted, the Ably REST API default of 60 minutes is applied by Ably. <br />_Default: 1 hour_ | <If lang="javascript,nodejs">`Integer` (milliseconds)</If><If lang="ruby">`Integer` (seconds)</If><If lang="objc,swift">`NSTimeInterval`</If><If lang="java">`Long Integer`</If><If lang="csharp">`TimeSpan`</If> |
@@ -911,7 +911,7 @@ A [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object
 | <If lang="javascript,nodejs,java,objc,swift">keyName</If><If lang="ruby">key_name</If><If lang="csharp">KeyName</If> | The key name of the key against which this request is made. The key name is public, whereas the key secret is private | `String` |
 | <If lang="javascript,nodejs,java,objc,swift,ruby">ttl</If><If lang="csharp">Ttl</If> | Requested time to live for the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) <If lang="javascript,nodejs,java,objc,swift">in milliseconds</If><If lang="ruby">in seconds</If><If lang="csharp,go">as a `TimeSpan`</If>. If the Ably `TokenRequest` is successful, the TTL of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be less than or equal to this value depending on application settings and the attributes of the issuing key. | <If lang="javascript,nodejs,java">`Integer`</If><If lang="csharp">`TimeSpan`</If><If lang="swift,objc">`NSTimeInterval`</If> |
 | <If lang="javascript,nodejs,java,ruby,objc,swift">timestamp</If><If lang="csharp">Timestamp</If> | The timestamp of this request<If lang="javascript,nodejs,java"> in milliseconds</If><If lang="ruby,csharp"></If> | <If lang="javascript,nodejs">`Integer`</If><If lang="java">`Long Integer`</If><If lang="ruby">`Time`</If><If lang="csharp">`DateTimeOffset`</If><If lang="swift,obj">`NSDate`</If> |
-| <If lang="javascript,nodejs,java,objc,swift,ruby">capability</If><If lang="csharp,go">Capability</If> | Capability of the requested [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the Ably `TokenRequest` is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. The capability is a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/auth) | `String` |
+| <If lang="javascript,nodejs,java,objc,swift,ruby">capability</If><If lang="csharp,go">Capability</If> | Capability of the requested [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the Ably `TokenRequest` is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. The capability is a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/platform/auth) | `String` |
 | <If lang="javascript,nodejs,java,objc,swift">clientId</If><If lang="ruby">client_id</If><If lang="csharp">ClientId</If> | The client ID to associate with the requested [Ably Token](/docs/api/realtime-sdk/authentication#token-details). When provided, the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) may only be used to perform operations on behalf of that client ID | `String` |
 | <If lang="javascript,nodejs,java,objc,swift,ruby">nonce</If><If lang="csharp">Nonce</If> | An opaque nonce string of at least 16 characters | `String` |
 | <If lang="javascript,nodejs,java,objc,swift,ruby">mac</If><If lang="csharp">Mac</If> | The Message Authentication Code for this request | `String` |
@@ -958,7 +958,7 @@ An Ably JWT is not strictly an Ably construct, rather it is a [JWT](https://jwt.
 
 Arbitrary additional claims and headers are supported (apart from those prefixed with `x-ably-` which are reserved for future use).
 
-The Ably JWT must be signed with the secret part of your [Ably API key](/docs/auth#api-key) using the signature algorithm HS256 (HMAC using the SHA-256 hash algorithm). View the [JSON Web Algorithms (JWA) specification](https://tools.ietf.org/html/rfc7518) for further information.
+The Ably JWT must be signed with the secret part of your [Ably API key](/docs/platform/auth#api-key) using the signature algorithm HS256 (HMAC using the SHA-256 hash algorithm). View the [JSON Web Algorithms (JWA) specification](https://tools.ietf.org/html/rfc7518) for further information.
 
 We recommend you use one of the many [JWT libraries available for simplicity](https://jwt.io/) when creating your JWTs.
 
diff --git a/src/pages/docs/api/realtime-sdk/channels.mdx b/src/pages/docs/api/realtime-sdk/channels.mdx
index 4088e43aba..8c65350bca 100644
--- a/src/pages/docs/api/realtime-sdk/channels.mdx
+++ b/src/pages/docs/api/realtime-sdk/channels.mdx
@@ -840,7 +840,7 @@ Failure to retrieve the message history will trigger the `errback` callbacks of
 `Message get_message(serial_or_message)`
 </If>
 
-Retrieves the latest version of a specific message by its serial identifier. Requires the **history** [capability](/docs/auth/capabilities).
+Retrieves the latest version of a specific message by its serial identifier. Requires the **history** [capability](/docs/platform/auth/capabilities).
 
 See [updating and deleting messages: retrieving the latest version](/docs/messages/updates-deletes#get) for more information.
 
@@ -892,7 +892,7 @@ On failure, raises an [`AblyException`](/docs/api/realtime-sdk/types#ably-except
 `UpdateDeleteResult update_message(message, operation=None, params=dict())`
 </If>
 
-Publishes an update to an existing message with shallow mixin semantics. Non-null `name`, `data`, and `extras` fields in the provided message will replace the corresponding fields in the existing message, while null fields will be left unchanged. Requires the **message-update-own** or **message-update-any** [capability](/docs/auth/capabilities).
+Publishes an update to an existing message with shallow mixin semantics. Non-null `name`, `data`, and `extras` fields in the provided message will replace the corresponding fields in the existing message, while null fields will be left unchanged. Requires the **message-update-own** or **message-update-any** [capability](/docs/platform/auth/capabilities).
 
 See [updating and deleting messages: updates](/docs/messages/updates-deletes#update) for more information.
 
@@ -937,7 +937,7 @@ On failure, raises an [`AblyException`](/docs/api/realtime-sdk/types#ably-except
 `UpdateDeleteResult delete_message(message, operation=None, params=dict())`
 </If>
 
-Marks a message as deleted by publishing an update with an action of `MESSAGE_DELETE`. This does not remove the message from the server, and the full message history remains accessible. Uses shallow mixin semantics: non-null `name`, `data`, and `extras` fields in the provided message will replace the corresponding fields in the existing message, while null fields will be left unchanged. Requires the **message-delete-own** or **message-delete-any** [capability](/docs/auth/capabilities).
+Marks a message as deleted by publishing an update with an action of `MESSAGE_DELETE`. This does not remove the message from the server, and the full message history remains accessible. Uses shallow mixin semantics: non-null `name`, `data`, and `extras` fields in the provided message will replace the corresponding fields in the existing message, while null fields will be left unchanged. Requires the **message-delete-own** or **message-delete-any** [capability](/docs/platform/auth/capabilities).
 
 See [updating and deleting messages: deletes](/docs/messages/updates-deletes#delete) for more information.
 
@@ -982,7 +982,7 @@ On failure, raises an [`AblyException`](/docs/api/realtime-sdk/types#ably-except
 `UpdateDeleteResult append_message(message, operation=None, params=dict())`
 </If>
 
-Appends data to an existing message. The supplied `data` field is appended to the previous message's data, while all other fields (`name`, `extras`) replace the previous values if provided. Requires the **message-update-own** or **message-update-any** [capability](/docs/auth/capabilities).
+Appends data to an existing message. The supplied `data` field is appended to the previous message's data, while all other fields (`name`, `extras`) replace the previous values if provided. Requires the **message-update-own** or **message-update-any** [capability](/docs/platform/auth/capabilities).
 
 See [updating and deleting messages: appends](/docs/messages/updates-deletes#append) for more information.
 
@@ -1027,7 +1027,7 @@ On failure, raises an [`AblyException`](/docs/api/realtime-sdk/types#ably-except
 `PaginatedResult get_message_versions(serial_or_message, params = dict())`
 </If>
 
-Retrieves all historical versions of a specific message, ordered by version. This includes the original message and all subsequent updates or delete operations. Requires the **history** [capability](/docs/auth/capabilities).
+Retrieves all historical versions of a specific message, ordered by version. This includes the original message and all subsequent updates or delete operations. Requires the **history** [capability](/docs/platform/auth/capabilities).
 
 See [updating and deleting messages: message versions](/docs/messages/updates-deletes#versions) for more information.
 
diff --git a/src/pages/docs/api/realtime-sdk/presence.mdx b/src/pages/docs/api/realtime-sdk/presence.mdx
index d612324043..69f9a5bdf5 100644
--- a/src/pages/docs/api/realtime-sdk/presence.mdx
+++ b/src/pages/docs/api/realtime-sdk/presence.mdx
@@ -870,7 +870,7 @@ Unsubscribes all listeners to presence message events on this channel. This remo
 
 ### <If lang="javascript,nodejs,java,objc,swift">enterClient</If><If lang="ruby">enter_client</If><If lang="csharp">EnterClientAsync</If> <a id="enter-client" />
 
-Enter this presence channel for the given <If lang="flutter,javascript,nodejs,java,swift,objc">`clientId`</If><If lang="ruby">`client_id`</If><If lang="csharp">`ClientId`</If>. This method is provided to support typically server instances that act on behalf of multiple client IDs. See [Managing multiple client IDs](/docs/presence-occupancy/presence#presence-multiple-client-id) for more info. In order to be able to publish presence changes for arbitrary client IDs, the client library must have been instantiated either with an [API key](/docs/auth#api-keys,) or with a [token bound to a wildcard client ID](https://faqs.ably.com/can-a-client-emulate-any-client-id-i.e.-authenticate-using-a-wildcard-client-id.)
+Enter this presence channel for the given <If lang="flutter,javascript,nodejs,java,swift,objc">`clientId`</If><If lang="ruby">`client_id`</If><If lang="csharp">`ClientId`</If>. This method is provided to support typically server instances that act on behalf of multiple client IDs. See [Managing multiple client IDs](/docs/presence-occupancy/presence#presence-multiple-client-id) for more info. In order to be able to publish presence changes for arbitrary client IDs, the client library must have been instantiated either with an [API key](/docs/platform/auth#api-keys,) or with a [token bound to a wildcard client ID](https://faqs.ably.com/can-a-client-emulate-any-client-id-i.e.-authenticate-using-a-wildcard-client-id.)
 
 <If lang="flutter,ruby,java,swift,objc,csharp">
 
diff --git a/src/pages/docs/api/realtime-sdk/push-admin.mdx b/src/pages/docs/api/realtime-sdk/push-admin.mdx
index 53b8b171dd..917d36d660 100644
--- a/src/pages/docs/api/realtime-sdk/push-admin.mdx
+++ b/src/pages/docs/api/realtime-sdk/push-admin.mdx
@@ -27,7 +27,7 @@ The returned [`DeviceRegistrations`](#device-registrations-object) object provid
 
 #### <If lang="javascript,nodejs,java,objc,swift">channelSubscriptions</If><If lang="python,ruby">channel_subscriptions</If> <a id="channel-subscriptions" />
 
-The returned [`PushChannelSubscriptions`](#push-channel-subscriptions) object provides functionality for subscribing, listing and unsubscribing individual devices or groups of [identified devices](/docs/auth/identified-clients) to push notifications published on channels.
+The returned [`PushChannelSubscriptions`](#push-channel-subscriptions) object provides functionality for subscribing, listing and unsubscribing individual devices or groups of [identified devices](/docs/platform/auth/identified-clients) to push notifications published on channels.
 
 ### Methods <a id="methods" />
 
@@ -59,7 +59,7 @@ The returned [`PushChannelSubscriptions`](#push-channel-subscriptions) object pr
 
 </If>
 
-Publishes a push notification directly to a device or group of devices sharing a [client identifier](/docs/auth/identified-clients). See the [push notification direct publishing documentation](/docs/push/publish#direct-publishing) for more information.
+Publishes a push notification directly to a device or group of devices sharing a [client identifier](/docs/platform/auth/identified-clients). See the [push notification direct publishing documentation](/docs/push/publish#direct-publishing) for more information.
 
 ##### Parameters
 
@@ -623,7 +623,7 @@ This object is accessible through <If lang="javascript,nodejs,java,python,objc,s
 
 </If>
 
-Retrieve all push channel subscriptions that match the provided params filter as a paginated list of [`PushChannelSubscription`](#push-channel-subscription) objects. Each [`PushChannelSubscription`](#push-channel-subscription) represents a device or set of devices sharing the same [client identifier](/docs/auth/identified-clients) registered to a channel to receive push notifications.
+Retrieve all push channel subscriptions that match the provided params filter as a paginated list of [`PushChannelSubscription`](#push-channel-subscription) objects. Each [`PushChannelSubscription`](#push-channel-subscription) represents a device or set of devices sharing the same [client identifier](/docs/platform/auth/identified-clients) registered to a channel to receive push notifications.
 
 ##### Parameters
 
@@ -796,7 +796,7 @@ Failure to retrieve the channels will trigger the `errback` callbacks of the [`D
 
 </If>
 
-Subscribe a device or group of devices sharing a [client identifier](/docs/auth/identified-clients) for push notifications published on a channel.
+Subscribe a device or group of devices sharing a [client identifier](/docs/platform/auth/identified-clients) for push notifications published on a channel.
 
 ##### Parameters
 
@@ -849,7 +849,7 @@ On failure to create or update the channel subscription, `err` contains an [`Err
 
 </If>
 
-Unsubscribe a device or group of devices sharing a [client identifier](/docs/auth/identified-clients) from push notifications on a channel. Requires `push-admin` permission or, in the case of a subscription associated with a given `deviceId`, `push-subscribe` permission together with device authentication matching that `deviceId`.
+Unsubscribe a device or group of devices sharing a [client identifier](/docs/platform/auth/identified-clients) from push notifications on a channel. Requires `push-admin` permission or, in the case of a subscription associated with a given `deviceId`, `push-subscribe` permission together with device authentication matching that `deviceId`.
 
 ##### Parameters
 
@@ -946,7 +946,7 @@ A `DeviceDetails` is a type encapsulating attributes of a device registered for
 | Property | Description | Type |
 |----------|------|-------------|
 | id | Unique identifier for the device generated by the device itself | `String` |
-| <If lang="javascript,nodejs,java,python,objc,swift">clientId</If><If lang="ruby">client_id</If> | Optional trusted [client identifier](/docs/auth/identified-clients) for the device | `String` |
+| <If lang="javascript,nodejs,java,python,objc,swift">clientId</If><If lang="ruby">client_id</If> | Optional trusted [client identifier](/docs/platform/auth/identified-clients) for the device | `String` |
 | <If lang="javascript,nodejs,java,python,objc,swift">formFactor</If><If lang="ruby">form_factor</If> | Form factor of the push device. Must be one of `phone`, `tablet`, `desktop`, `tv`, `watch`, `car` <If lang="java,ruby,python,objc,swift">or `embedded`</If><If lang="javascript,nodejs">`embedded` or `other`</If> | `String` |
 | metadata | Optional metadata object for this device. The metadata for a device may only be set by clients with `push-admin` privileges | <If lang="javascript,nodejs,java,python,objc,swift">`Object`</If><If lang="ruby">`Hash`</If> |
 | platform | Platform of the push device. Must be one of `ios` <If lang="java,ruby,python,objc,swift">or `android`</If><If lang="javascript,nodejs">`android` or `browser`</If> | `String` |
@@ -1140,7 +1140,7 @@ Failure to retrieve the message history will raise an [`AblyException`](/docs/ap
 
 ### <If lang="javascript,nodejs,python">PushChannelSubscription</If><If lang="objc,swift">ARTPushChannelSubscription</If><If lang="java">ChannelSubscription</If><If lang="ruby">Art::Models::PushChannelSubscription</If> <a id="push-channel-subscription" />
 
-An `PushChannelSubscription` is a type encapsulating the subscription of a device or group of devices sharing a [client identifier](/docs/auth/identified-clients) to a channel in order to receive push notifications.
+An `PushChannelSubscription` is a type encapsulating the subscription of a device or group of devices sharing a [client identifier](/docs/platform/auth/identified-clients) to a channel in order to receive push notifications.
 
 #### <If lang="javascript,nodejs,python,objc,swift">Properties</If><If lang="java">Members</If><If lang="ruby">Attributes</If>
 
@@ -1148,7 +1148,7 @@ An `PushChannelSubscription` is a type encapsulating the subscription of a devic
 |----------|------|-------------|
 | channel | The channel that this push notification subscription is associated with | `String` |
 | <If lang="javascript,nodejs,java,python,objc,swift">deviceId</If><If lang="ruby">device_id</If> | The device with this identifier is linked to this channel subscription. When present, <If lang="javascript,nodejs,java,python,objc,swift">`clientId`</If><If lang="ruby">`client_id`</If> is never present | `String` |
-| <If lang="javascript,nodejs,java,python,objc,swift">clientId</If><If lang="ruby">client_id</If> | Devices with this [client identifier](/docs/auth/identified-clients) are included in this channel subscription. When present, <If lang="javascript,nodejs,java,python,objc,swift">`deviceId`</If><If lang="ruby">`device_id`</If> is never present | `String` |
+| <If lang="javascript,nodejs,java,python,objc,swift">clientId</If><If lang="ruby">client_id</If> | Devices with this [client identifier](/docs/platform/auth/identified-clients) are included in this channel subscription. When present, <If lang="javascript,nodejs,java,python,objc,swift">`deviceId`</If><If lang="ruby">`device_id`</If> is never present | `String` |
 
 <If lang="java,python,objc,swift,ruby">
 
@@ -1193,14 +1193,14 @@ A [`PushChannelSubscription`](/docs/api/realtime-sdk/types#push-channel-subscrip
 
 </If>
 
-A static factory method to create a `PushChannelSubscription` object for a channel and group of devices sharing a [client identifier](/docs/auth/identified-clients).
+A static factory method to create a `PushChannelSubscription` object for a channel and group of devices sharing a [client identifier](/docs/platform/auth/identified-clients).
 
 ##### Parameters
 
 | Parameter | Description | Type |
 |-----------|------|-------------|
 | channel | Channel name linked to this push channel subscription | `String` |
-| <If lang="javascript,nodejs,java,python,objc,swift">clientId</If><If lang="ruby">client_id</If> | Devices with this [client identifier](/docs/auth/identified-clients) are included in the new push channel subscription | `String` |
+| <If lang="javascript,nodejs,java,python,objc,swift">clientId</If><If lang="ruby">client_id</If> | Devices with this [client identifier](/docs/platform/auth/identified-clients) are included in the new push channel subscription | `String` |
 
 ##### Returns
 
diff --git a/src/pages/docs/api/realtime-sdk/push.mdx b/src/pages/docs/api/realtime-sdk/push.mdx
index 89196da0e7..8fbe075d93 100644
--- a/src/pages/docs/api/realtime-sdk/push.mdx
+++ b/src/pages/docs/api/realtime-sdk/push.mdx
@@ -124,7 +124,7 @@ A `DeviceDetails` is a type encapsulating attributes of a device registered for
 | Property | Description | Type |
 |----------|-------------|------|
 | id | Unique identifier for the device generated by the device itself | `String` |
-| clientId | Optional trusted [client identifier](/docs/auth/identified-clients) for the device | `String` |
+| clientId | Optional trusted [client identifier](/docs/platform/auth/identified-clients) for the device | `String` |
 | formFactor | Form factor of the push device. Must be one of `phone`, `tablet`, `desktop`, `tv`, `watch`, `car` <If lang="java,objc,swift">or `embedded`</If><If lang="javascript,nodejs">`embedded` or `other`</If> | `String` |
 | metadata | Optional metadata object for this device. The metadata for a device may only be set by clients with `push-admin` privileges | `Object` |
 | platform | Platform of the push device. Must be one of `ios` <If lang="java,objc,swift">or `android`</If><If lang="javascript,nodejs">`android` or `browser`</If> | `String` |
@@ -361,7 +361,7 @@ Failure to retrieve the message history will raise an [`AblyException`](/docs/ap
 
 ### <If lang="javascript,nodejs">PushChannelSubscription</If><If lang="java">ChannelSubscription</If><If lang="objc,swift">ARTPushChannelSubscription</If> <a id="push-channel-subscription" />
 
-A `PushChannelSubscription` is a type encapsulating the subscription of a device or group of devices sharing a [client identifier](/docs/auth/identified-clients) to a channel in order to receive push notifications.
+A `PushChannelSubscription` is a type encapsulating the subscription of a device or group of devices sharing a [client identifier](/docs/platform/auth/identified-clients) to a channel in order to receive push notifications.
 
 #### <If lang="javascript,nodejs,objc,swift">Properties</If><If lang="java">Members</If>
 
@@ -369,7 +369,7 @@ A `PushChannelSubscription` is a type encapsulating the subscription of a device
 |----------|-------------|------|
 | channel | The channel that this push notification subscription is associated with | `String` |
 | deviceId | The device with this identifier is linked to this channel subscription. When present, `clientId` is never present | `String` |
-| clientId | Devices with this [client identifier](/docs/auth/identified-clients) are included in this channel subscription. When present, `deviceId` is never present | `String` |
+| clientId | Devices with this [client identifier](/docs/platform/auth/identified-clients) are included in this channel subscription. When present, `deviceId` is never present | `String` |
 
 <If lang="java,objc,swift">
 
@@ -396,14 +396,14 @@ A [`PushChannelSubscription`](/docs/api/realtime-sdk/types#push-channel-subscrip
 
 `PushChannelSubscription.forClient(String channel, String clientId) -> PushChannelSubscription`
 
-A static factory method to create a `PushChannelSubscription` object for a channel and group of devices sharing a [client identifier](/docs/auth/identified-clients).
+A static factory method to create a `PushChannelSubscription` object for a channel and group of devices sharing a [client identifier](/docs/platform/auth/identified-clients).
 
 ##### Parameters
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
 | channel | Channel name linked to this push channel subscription | `String` |
-| clientId | Devices with this [client identifier](/docs/auth/identified-clients) are included in the new push channel subscription | `String` |
+| clientId | Devices with this [client identifier](/docs/platform/auth/identified-clients) are included in the new push channel subscription | `String` |
 
 ##### Returns
 
diff --git a/src/pages/docs/api/realtime-sdk/types.mdx b/src/pages/docs/api/realtime-sdk/types.mdx
index 8232bbcb44..5404bf7057 100644
--- a/src/pages/docs/api/realtime-sdk/types.mdx
+++ b/src/pages/docs/api/realtime-sdk/types.mdx
@@ -142,7 +142,7 @@ A `DeviceDetails` is a type encapsulating attributes of a device registered for
 | Property | Description | Type |
 |----------|-------------|------|
 | id | unique identifier for the device generated by the device itself | `String` |
-| <If lang="flutter">clientId</If><If lang="ruby">client_id</If> | optional trusted [client identifier](/docs/auth/identified-clients) for the device | `String` |
+| <If lang="flutter">clientId</If><If lang="ruby">client_id</If> | optional trusted [client identifier](/docs/platform/auth/identified-clients) for the device | `String` |
 | <If lang="flutter">formFactor</If><If lang="ruby">form_factor</If> | form factor of the push device. Must be one of `phone`, `tablet`, `desktop`, `tv`, `watch`, `car`, or `embedded` | `String` |
 | metadata | optional metadata object for this device. The metadata for a device may only be set by clients with `push-admin` privileges | `Object` |
 | platform | platform of the push device. Must be one of `ios` or `android` | `String` |
@@ -1335,7 +1335,7 @@ Please note that `key` and `value` attributes are always strings. If an `Integer
 
 ### <If lang="javascript,nodejs">PushChannelSubscription</If><If lang="ruby">Ably::Models::PushChannelSubscription</If> <a id="push-channel-subscription" />
 
-An `PushChannelSubscription` is a type encapsulating the subscription of a device or group of devices sharing a [client identifier](/docs/auth/identified-clients) to a channel in order to receive push notifications.
+An `PushChannelSubscription` is a type encapsulating the subscription of a device or group of devices sharing a [client identifier](/docs/platform/auth/identified-clients) to a channel in order to receive push notifications.
 
 #### Properties
 
@@ -1343,7 +1343,7 @@ An `PushChannelSubscription` is a type encapsulating the subscription of a devic
 |----------|-------------|------|
 | channel | The channel that this push notification subscription is associated with | `String` |
 | <If lang="javascript,nodejs">deviceId</If><If lang="ruby">device_id</If> | The device with this identifier is linked to this channel subscription. When present, <If lang="javascript,nodejs">`clientId`</If><If lang="ruby">`client_id`</If> is never present | `String` |
-| <If lang="javascript,nodejs">clientId</If><If lang="ruby">client_id</If> | Devices with this [client identifier](/docs/auth/identified-clients) are included in this channel subscription. When present, <If lang="javascript,nodejs">`deviceId`</If><If lang="ruby">`device_id`</If> is never present | `String` |
+| <If lang="javascript,nodejs">clientId</If><If lang="ruby">client_id</If> | Devices with this [client identifier](/docs/platform/auth/identified-clients) are included in this channel subscription. When present, <If lang="javascript,nodejs">`deviceId`</If><If lang="ruby">`device_id`</If> is never present | `String` |
 
 </If>
 
@@ -1390,14 +1390,14 @@ A [`PushChannelSubscription`](/docs/api/realtime-sdk/types#push-channel-subscrip
 
 </If>
 
-A static factory method to create a `PushChannelSubscription` object for a channel and group of devices sharing a [client identifier](/docs/auth/identified-clients).
+A static factory method to create a `PushChannelSubscription` object for a channel and group of devices sharing a [client identifier](/docs/platform/auth/identified-clients).
 
 ##### Parameters
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
 | channel | Channel name linked to this push channel subscription | `String` |
-| <If lang="flutter,java,csharp,objc,swift,go">clientId</If><If lang="ruby">client_id</If> | Devices with this [client identifier](/docs/auth/identified-clients) are included in the new push channel subscription | `String` |
+| <If lang="flutter,java,csharp,objc,swift,go">clientId</If><If lang="ruby">client_id</If> | Devices with this [client identifier](/docs/platform/auth/identified-clients) are included in the new push channel subscription | `String` |
 
 ##### Returns
 
@@ -1416,8 +1416,8 @@ A `PushChannelSubscription` object
 | <If lang="javascript,nodejs,java,objc,swift,ruby,flutter">token</If><If lang="csharp,go">Token</If> | The [Ably Token](/docs/api/realtime-sdk/authentication#token-details) itself. A typical [Ably Token](/docs/api/realtime-sdk/authentication#token-details) string may appear like `{{TOKEN}}` | `String` |
 | <If lang="javascript,nodejs,java,objc,swift,ruby,flutter">expires</If><If lang="csharp,go">Expires</If> | <If lang="javascript,nodejs,java,flutter,csharp,go">The time (in milliseconds since the epoch)</If><If lang="ruby,objc,swift">The time</If> at which this token expires | <If lang="javascript,nodejs,flutter">`Integer`</If><If lang="java">`Long Integer`</If><If lang="csharp">`DateTimeOffset`</If><If lang="ruby">`Time`</If><If lang="objc,swift">`NSDate`</If> |
 | <If lang="javascript,nodejs,java,objc,swift,ruby,flutter">issued</If><If lang="csharp,go">Issued</If> | <If lang="javascript,nodejs,java,flutter,csharp,go">The time (in milliseconds since the epoch)</If><If lang="ruby,objc,swift">The time</If> at which this token was issued | <If lang="javascript,nodejs,flutter">`Integer`</If><If lang="java">`Long Integer`</If><If lang="csharp">`DateTimeOffset`</If><If lang="ruby">`Time`</If><If lang="objc,swift">`NSDate`</If> |
-| <If lang="javascript,nodejs,java,objc,swift,ruby,flutter">capability</If><If lang="csharp,go">Capability</If> | The capability associated with this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The capability is a a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/auth/capabilities) | <If lang="javascript,nodejs,java,objc,swift,ruby,flutter,go">`String`</If><If lang="csharp">`Capability`</If> |
-| <If lang="javascript,nodejs,java,objc,swift,flutter">clientId</If><If lang="ruby">client_id</If><If lang="csharp,go">ClientId</If> | The client ID, if any, bound to this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If a client ID is included, then the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) authenticates its bearer as that client ID, and the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) may only be used to perform operations on behalf of that client ID. The client is then considered to be an [identified client](/docs/auth/identified-clients) | `String` |
+| <If lang="javascript,nodejs,java,objc,swift,ruby,flutter">capability</If><If lang="csharp,go">Capability</If> | The capability associated with this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The capability is a a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/platform/auth/capabilities) | <If lang="javascript,nodejs,java,objc,swift,ruby,flutter,go">`String`</If><If lang="csharp">`Capability`</If> |
+| <If lang="javascript,nodejs,java,objc,swift,flutter">clientId</If><If lang="ruby">client_id</If><If lang="csharp,go">ClientId</If> | The client ID, if any, bound to this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If a client ID is included, then the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) authenticates its bearer as that client ID, and the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) may only be used to perform operations on behalf of that client ID. The client is then considered to be an [identified client](/docs/platform/auth/identified-clients) | `String` |
 
 <If lang="ruby">
 
@@ -1506,7 +1506,7 @@ A [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object
 | <If lang="javascript,nodejs,java,objc,swift,flutter">keyName</If><If lang="ruby">key_name</If><If lang="csharp,go">KeyName</If> | The key name of the key against which this request is made. The key name is public, whereas the key secret is private | `String` |
 | <If lang="javascript,nodejs,java,objc,swift,ruby,go,flutter">ttl</If><If lang="csharp">Ttl</If> | Requested time to live for the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) <If lang="javascript,nodejs,java,objc,swift,flutter">in milliseconds</If><If lang="ruby">in seconds</If><If lang="csharp,go">as a `TimeSpan`</If>. If the Ably `TokenRequest` is successful, the TTL of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be less than or equal to this value depending on application settings and the attributes of the issuing key. | <If lang="javascript,nodejs,java,ruby,go,flutter">`Integer`</If><If lang="csharp">`TimeSpan`</If><If lang="swift,objc">`NSTimeInterval`</If> |
 | <If lang="javascript,nodejs,java,objc,swift,ruby,flutter">timestamp</If><If lang="csharp,go">Timestamp</If> | The timestamp of this request<If lang="javascript,nodejs,java,objc,swift,flutter"> in milliseconds</If> | <If lang="javascript,nodejs,objc,swift,flutter">`Integer`</If><If lang="java">`Long Integer`</If><If lang="ruby">`Time`</If><If lang="csharp">`DateTimeOffset`</If><If lang="go">`Integer`</If> |
-| <If lang="javascript,nodejs,java,objc,swift,ruby,flutter">capability</If><If lang="csharp,go">Capability</If> | Capability of the requested [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the Ably `TokenRequest` is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. The capability is a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/auth) | `String` |
+| <If lang="javascript,nodejs,java,objc,swift,ruby,flutter">capability</If><If lang="csharp,go">Capability</If> | Capability of the requested [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the Ably `TokenRequest` is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. The capability is a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/platform/auth) | `String` |
 | <If lang="javascript,nodejs,java,objc,swift,flutter">clientId</If><If lang="ruby">client_id</If><If lang="csharp,go">ClientId</If> | The client ID to associate with the requested [Ably Token](/docs/api/realtime-sdk/authentication#token-details). When provided, the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) may only be used to perform operations on behalf of that client ID | `String` |
 | <If lang="javascript,nodejs,java,objc,swift,ruby,flutter">nonce</If><If lang="csharp,go">Nonce</If> | An opaque nonce string of at least 16 characters | `String` |
 | <If lang="javascript,nodejs,java,objc,swift,ruby,flutter">mac</If><If lang="csharp,go">Mac</If> | The Message Authentication Code for this request | `String` |
@@ -1836,19 +1836,19 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 <If lang="javascript,nodejs">
 
-`AuthOptions` is a plain JavaScript object and is used when making [authentication](/docs/auth) requests. If passed in, an `authOptions` object will be used instead of (as opposed to supplementing or being merged with) the default values given when the library was instantiated. The following attributes are supported:
+`AuthOptions` is a plain JavaScript object and is used when making [authentication](/docs/platform/auth) requests. If passed in, an `authOptions` object will be used instead of (as opposed to supplementing or being merged with) the default values given when the library was instantiated. The following attributes are supported:
 
 </If>
 
 <If lang="ruby">
 
-`AuthOptions` is a Hash object and is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following key symbol values can be added to the Hash:
+`AuthOptions` is a Hash object and is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following key symbol values can be added to the Hash:
 
 </If>
 
 <If lang="java,swift,objc,go">
 
-<If lang="swift,objc">`ART`</If>`AuthOptions` is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated.
+<If lang="swift,objc">`ART`</If>`AuthOptions` is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated.
 
 </If>
 
@@ -1870,15 +1870,15 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Property | Description | Type |
 |----------|-------------|------|
-| <If lang="javascript,nodejs,java,objc,swift,flutter">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="ruby">:auth_callback</If> | A <If lang="javascript,nodejs,java,objc,swift,csharp,go,ruby,flutter">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,objc,swift,flutter">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If><If lang="csharp">`Func<TokenParams, Task<object>>`</If> |
+| <If lang="javascript,nodejs,java,objc,swift,flutter">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="ruby">:auth_callback</If> | A <If lang="javascript,nodejs,java,objc,swift,csharp,go,ruby,flutter">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,objc,swift,flutter">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If><If lang="csharp">`Func<TokenParams, Task<object>>`</If> |
 | <If lang="javascript,nodejs,java,objc,swift,flutter">authUrl</If><If lang="csharp,go">AuthUrl</If><If lang="ruby">:auth_url</If> | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | <If lang="javascript,nodejs,java,go,flutter">`String`</If><If lang="csharp">`Uri`</If><If lang="swift,objc">`NSURL`</If><If lang="ruby">`String`</If> |
 | <If lang="javascript,nodejs,java,objc,swift,flutter">authMethod</If><If lang="csharp,go">AuthMethod</If><If lang="ruby">:auth_method</If> | _<If lang="javascript,nodejs,java,objc,swift,csharp,go,flutter">`GET`</If><If lang="ruby">`:get`</If>_ The HTTP verb to use for the request, either <If lang="javascript,nodejs,java,objc,swift,csharp,go,flutter">`GET`</If><If lang="ruby">`:get`</If> or <If lang="javascript,nodejs,java,objc,swift,csharp,go,flutter">`POST`</If><If lang="ruby">`:post`</If> | <If lang="javascript,nodejs,java,objc,swift,go,flutter">`String`</If><If lang="ruby">`Symbol`</If><If lang="csharp">`HttpMethod`</If> |
 | <If lang="javascript,nodejs,java,objc,swift,flutter">authHeaders</If><If lang="csharp,go">AuthHeaders</If><If lang="ruby">:auth_headers</If> | A set of key value pair headers to be added to any request made to the <If lang="javascript,nodejs,java,objc,swift,flutter">authUrl</If><If lang="csharp">AuthUrl</If><If lang="ruby">:auth_url</If>. Useful when an application requires these to be added to validate the request or implement the response. <If lang="javascript">If the `authHeaders` object contains an `authorization` key, then `withCredentials` will be set on the xhr request.</If> | <If lang="javascript,nodejs">`Object`</If><If lang="ruby">`Hash`</If><If lang="java">`Param[]`</If><If lang="csharp">`Dictionary<string, string>`</If><If lang="flutter">`Map<String, String>`</If> |
 | <If lang="javascript,nodejs,java,objc,swift,flutter">authParams</If><If lang="csharp,go">AuthParams</If><If lang="ruby">:auth_params</If> | A set of key value pair params to be added to any request made to the <If lang="javascript,nodejs,java,objc,swift,flutter">authUrl</If><If lang="csharp">AuthUrl</If><If lang="ruby">:auth_url</If>. When the <If lang="javascript,nodejs,java,objc,swift,flutter">authMethod</If><If lang="csharp,go">AuthMethod</If><If lang="ruby">:auth_method</If> is `GET`, query params are added to the URL, whereas when <If lang="javascript,nodejs,java,objc,swift,flutter">authMethod</If><If lang="csharp,go">AuthMethod</If><If lang="ruby">:auth_method</If> is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | <If lang="javascript,nodejs">`Object`</If><If lang="ruby">`Hash`</If><If lang="java">`Param[]`</If><If lang="csharp">`Dictionary<string, string>`</If><If lang="objc">`NSArray<NSURLQueryItem *>`</If><If lang="swift">`[NSURLQueryItem]/Array<NSURLQueryItem>`</If><If lang="flutter">`Map<String, String>`</If> |
-| <If lang="javascript,nodejs,java,objc,swift,flutter">tokenDetails</If><If lang="csharp,go">TokenDetails</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,swift,flutter">authUrl</If><If lang="csharp,go">AuthUrl</If><If lang="ruby">:auth_url</If> or <If lang="javascript,nodejs,java,objc,swift,flutter">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="ruby">:auth_callback</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
-| <If lang="javascript,nodejs,java,objc,swift,flutter">key</If><If lang="csharp,go">Key</If><If lang="ruby">:key</If> | Optionally the [API key](/docs/auth#api-key) to use can be specified as a full key string; if not, the API key passed into [`ClientOptions`](#client-options) when instancing the Realtime or REST library is used | `String` |
-| <If lang="javascript,nodejs,java,objc,swift,flutter">queryTime</If><If lang="csharp,go">QueryTime</If><If lang="ruby">:query_time</If> | _false_ If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/auth/token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. | `Boolean` |
-| <If lang="javascript,nodejs,java,objc,swift,flutter">token</If><If lang="csharp,go">Token</If><If lang="ruby">:token</If> | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,java,objc,swift,flutter">token</If><If lang="csharp,go">Token</If><If lang="ruby">:token</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,swift,flutter">authUrl</If><If lang="csharp,go">AuthUrl</If><If lang="ruby">:auth_url</If> or <If lang="javascript,nodejs,java,objc,swift,flutter">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="ruby">:auth_callback</If>. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| <If lang="javascript,nodejs,java,objc,swift,flutter">tokenDetails</If><If lang="csharp,go">TokenDetails</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,swift,flutter">authUrl</If><If lang="csharp,go">AuthUrl</If><If lang="ruby">:auth_url</If> or <If lang="javascript,nodejs,java,objc,swift,flutter">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="ruby">:auth_callback</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
+| <If lang="javascript,nodejs,java,objc,swift,flutter">key</If><If lang="csharp,go">Key</If><If lang="ruby">:key</If> | Optionally the [API key](/docs/platform/auth#api-key) to use can be specified as a full key string; if not, the API key passed into [`ClientOptions`](#client-options) when instancing the Realtime or REST library is used | `String` |
+| <If lang="javascript,nodejs,java,objc,swift,flutter">queryTime</If><If lang="csharp,go">QueryTime</If><If lang="ruby">:query_time</If> | _false_ If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/platform/auth/token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. | `Boolean` |
+| <If lang="javascript,nodejs,java,objc,swift,flutter">token</If><If lang="csharp,go">Token</If><If lang="ruby">:token</If> | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,java,objc,swift,flutter">token</If><If lang="csharp,go">Token</If><If lang="ruby">:token</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,swift,flutter">authUrl</If><If lang="csharp,go">AuthUrl</If><If lang="ruby">:auth_url</If> or <If lang="javascript,nodejs,java,objc,swift,flutter">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="ruby">:auth_callback</If>. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
 
 ### <If lang="javascript,nodejs,flutter,go">ClientOptions Object</If><If lang="objc,swift">ARTClientOptions</If><If lang="ruby">ClientOptions Hash</If><If lang="java">io.ably.types.ClientOptions</If><If lang="csharp">IO.Ably.ClientOptions</If> <a id="client-options" />
 
@@ -1919,17 +1919,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Property | Description | Type |
 |----------|-------------|------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))` which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls | `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))` which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls | `Callable` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server | `String` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />**Default:** `GET` | `String` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. <If lang="javascript">If the `authHeaders` object contains an `authorization` key, then `withCredentials` will be set on the xhr request</If> | `Object` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response | `Object` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Default:** true | `Boolean` |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** null | `String` |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** null | `String` |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Default:** true | `Boolean` |
@@ -1944,7 +1944,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | transports | An optional array of transports to use, in descending order of preference. <If lang="javascript">In the browser environment the available transports are: `web_socket`, `xhr_polling`</If><If lang="nodejs">The transports available in the Node.js client library are: `web_socket`, `xhr_polling`, `comet`</If> | `String[]` |
 | recover | <If lang="javascript">This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the Realtime library. This might typically be used by clients of the browser library to ensure connection state can be preserved when the user refreshes the page. A recovery key string can be explicitly provided, or alternatively if a callback function is provided, the client library will automatically persist the recovery key between page reloads and call the callback when the connection is recoverable. The callback is then responsible for confirming whether the connection should be recovered or not. See [connection state recovery](/docs/connect/states) for further information</If><If lang="nodejs">This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the library by providing that connection's [`recoveryKey`](/docs/api/realtime-sdk/connection#recovery-key). This might typically be used by clients of an app to ensure connection state can be preserved following a reload. See [connection state recovery](/docs/connect/states) for further information and example code</If> | <If lang="javascript">`String`, `Callable`</If><If lang="nodejs">`String`</If> |
 | closeOnUnload | <If lang="javascript">When true, the client library will automatically send a close request to Ably whenever the `window beforeunload` event fires. By enabling this option, the close request sent to Ably ensures the connection state will not be retained and all channels associated with the connection will be detached. This is commonly used by developers who want presence leave events to fire immediately i.e. if a user navigates to another page or closes their browser, then enabling this option will result in the presence member leaving immediately. Without this option or an explicit call to the [`close`](/docs/api/realtime-sdk/connection#close) method of the [`Connection object`](/docs/api/realtime-sdk/connection), Ably expects that the abruptly disconnected connection could later be recovered and therefore does not immediately remove the user from presence. Instead, to avoid "twitchy" presence behavior an abruptly disconnected client is removed from channels in which they are present after 15 seconds, and the connection state is retained for two minutes<br />**Default:** true</If> | `Boolean` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
 | defaultTokenParams | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests | [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | disconnectedRetryTimeout | When the connection enters the `DISCONNECTED` state, after this delay in milliseconds, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Default:** 15,000ms | `Integer` |
 | suspendedRetryTimeout | When the connection enters the `SUSPENDED` state, after this delay in milliseconds, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Default:** 30,000ms | `Integer` |
@@ -1956,17 +1956,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Property | Description | Type |
 |----------|-------------|------|
-| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| Token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `Token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls | `Func<TokenParams, Task<object>>` |
+| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| Token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `Token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls | `Func<TokenParams, Task<object>>` |
 | AuthUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server | `Uri` |
 | AuthMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />**Default:** `GET` | `HttpMethod` |
 | AuthHeaders | A set of key value pair headers to be added to any request made to the `AuthUrl`. Useful when an application requires these to be added to validate the request or implement the response | `Dictionary<string, string>` |
 | AuthParams | A set of key value pair params to be added to any request made to the `AuthUrl`. When the `AuthMethod` is `GET`, query params are added to the URL, whereas when `AuthMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response | `Dictionary<string, string>` |
-| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | Tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Default:** true | `Boolean` |
-| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `ClientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `ClientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `ClientId` specified here conflicts with the `ClientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| UseTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
+| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `ClientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `ClientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `ClientId` specified here conflicts with the `ClientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| UseTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
 | Endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** null | `String` |
 | Environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** null | `String` |
 | IdempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Default:** true | `Boolean` |
@@ -1979,7 +1979,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | EchoMessages | If false, prevents messages originating from this connection being echoed back on the same connection<br />**Default:** true | `Boolean` |
 | AutoConnect | By default as soon as the client library is instantiated it will connect to Ably. You can optionally set this to false and explicitly connect to Ably when require using the [`connect`](/docs/api/realtime-sdk/connection#connect) method<br />**Default:** true | `Boolean` |
 | Recover | This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the library by providing that connection's [`recoveryKey`](/docs/api/realtime-sdk/connection#recovery-key). This might typically be used by clients of an app to ensure connection state can be preserved following a reload. See [connection state recovery](/docs/connect/states) for further information and example code | `String` |
-| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
+| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
 | DefaultTokenParams | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests | [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | DisconnectedRetryTimeout | When the connection enters the `DISCONNECTED` state, after this delay in milliseconds, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Default:** 15,000ms | `Integer` |
 | SuspendedRetryTimeout | When the connection enters the `SUSPENDED` state, after this delay in milliseconds, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Default:** 30,000ms | `Integer` |
@@ -1990,17 +1990,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Property | Description | Type |
 |----------|-------------|------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A `TokenCallback` instance which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls | `TokenCallback` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A `TokenCallback` instance which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls | `TokenCallback` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server | `String` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />**Default:** `GET` | `String` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response | `Param[]` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response | `Param[]` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Default:** true | `Boolean` |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** Null | `String` |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** Null | `String` |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Default:** true | `Boolean` |
@@ -2013,7 +2013,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | echoMessages | If false, prevents messages originating from this connection being echoed back on the same connection<br />**Default:** true | `Boolean` |
 | autoConnect | By default as soon as the client library is instantiated it will connect to Ably. You can optionally set this to false and explicitly connect to Ably when require using the [`connect`](/docs/api/realtime-sdk/connection#connect) method<br />**Default:** true | `Boolean` |
 | recover | This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the library by providing that connection's [`recoveryKey`](/docs/api/realtime-sdk/connection#recovery-key). This might typically be used by clients of an app to ensure connection state can be preserved following a reload. See [connection state recovery](/docs/connect/states) for further information and example code | `String` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
 | defaultTokenParams | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests | [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | disconnectedRetryTimeout | When the connection enters the `DISCONNECTED` state, after this delay in milliseconds, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Default:** 15,000ms | `Integer` |
 | suspendedRetryTimeout | When the connection enters the `SUSPENDED` state, after this delay in milliseconds, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Default:** 30,000ms | `Integer` |
@@ -2024,17 +2024,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Property | Description | Type |
 |----------|-------------|------|
-| :key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| :token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the :token property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as :auth_url or :auth_callback. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| :auth_callback | A proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter) which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls | `Proc` |
+| :key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| :token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the :token property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as :auth_url or :auth_callback. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| :auth_callback | A proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter) which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls | `Proc` |
 | :auth_url | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server | `String` |
 | :auth_method | The HTTP verb to use for the request, either `:get` or `:post`<br />**Default:** `:get` | `Symbol` |
 | :auth_headers | A set of key value pair headers to be added to any request made to the :auth_url. Useful when an application requires these to be added to validate the request or implement the response | `Hash` |
 | :auth_params | A set of key value pair params to be added to any request made to the :auth_url. When the :auth_method is `GET`, query params are added to the URL, whereas when :auth_method is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response | `Hash` |
-| :token_details | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as :auth_url or :auth_callback. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| :token_details | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as :auth_url or :auth_callback. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | :tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Default:** true | `Boolean` |
-| :client_id | A client ID, used for identifying this client when publishing messages or for presence purposes. The `client_id` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `client_id` may also be implicit in a token used to instantiate the library; an error will be raised if a `client_id` specified here conflicts with the `client_id` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| :use_token_auth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `client_id` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
+| :client_id | A client ID, used for identifying this client when publishing messages or for presence purposes. The `client_id` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `client_id` may also be implicit in a token used to instantiate the library; an error will be raised if a `client_id` specified here conflicts with the `client_id` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| :use_token_auth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `client_id` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
 | :endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** nil | `String` |
 | :environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** nil | `String` |
 | :idempotent_rest_publishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Default:** true | `Boolean` |
@@ -2047,7 +2047,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | :echo_messages | If false, prevents messages originating from this connection being echoed back on the same connection<br />**Default:** true | `Boolean` |
 | :auto_connect | By default as soon as the client library is instantiated it will connect to Ably. You can optionally set this to false and explicitly connect to Ably when require using the [`connect`](/docs/api/realtime-sdk/connection#connect) method<br />**Default:** true | `Boolean` |
 | :recover | This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the library by providing that connection's [`recovery_key`](/docs/api/realtime-sdk/connection#recovery-key). This might typically be used by clients of an app to ensure connection state can be preserved following a reload. See [connection state recovery](/docs/connect/states) for further information and example code | `String` |
-| :query_time | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
+| :query_time | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
 | :default_token_params | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests | [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | :disconnected_retry_timeout | When the connection enters the `DISCONNECTED` state, after this delay in seconds, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Default:** 15s | `Integer` |
 | :suspended_retry_timeout | When the connection enters the `SUSPENDED` state, after this delay in seconds, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Default:** 30s | `Integer` |
@@ -2058,17 +2058,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Property | Description | Type |
 |----------|-------------|------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls | `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls | `Callable` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server | `NSURL` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />**Default:** `GET` | `String` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response | `Object` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response | `[NSURLQueryItem]/Array<NSURLQueryItem>` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Default:** true | `Boolean` |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** nil | `String` |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** nil | `String` |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Default:** true | `Boolean` |
@@ -2082,7 +2082,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | echoMessages | If false, prevents messages originating from this connection being echoed back on the same connection<br />**Default:** true | `Boolean` |
 | autoConnect | By default as soon as the client library is instantiated it will connect to Ably. You can optionally set this to false and explicitly connect to Ably when require using the [`connect`](/docs/api/realtime-sdk/connection#connect) method<br />**Default:** true | `Boolean` |
 | recover | This option allows a connection to inherit the state of a previous connection that may have existed under a different instance of the library by providing that connection's [`recoveryKey`](/docs/api/realtime-sdk/connection#recovery-key). This might typically be used by clients of an app to ensure connection state can be preserved following a reload. See [connection state recovery](/docs/connect/states) for further information and example code | `String` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
 | defaultTokenParams | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests | [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | disconnectedRetryTimeout | When the connection enters the `DISCONNECTED` state, after this delay as a `NSTimeInterval`, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Default:** 15,000ms | `NSTimeInterval` |
 | suspendedRetryTimeout | When the connection enters the `SUSPENDED` state, after this delay as a `NSTimeInterval`, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Default:** 30,000ms | `NSTimeInterval` |
@@ -2093,17 +2093,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Property | Description | Type |
 |----------|-------------|------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls | `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls | `Callable` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server | `String` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />**Default:** `GET` | `String` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response | `Map<String, String>` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response | `Map<String, String>` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Default:** true | `Boolean` |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** null | `String` |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** null | `String` |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Default:** true | `Boolean` |
@@ -2113,7 +2113,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | queueMessages | If false, this disables the default behavior whereby the library queues messages on a connection in the disconnected or connecting states. The default behavior allows applications to submit messages immediately upon instancing the library without having to wait for the connection to be established. Applications may use this option to disable queueing if they wish to have application-level control over the queueing under those conditions<br />**Default:** true | `Boolean` |
 | echoMessages | If false, prevents messages originating from this connection being echoed back on the same connection<br />**Default:** true | `Boolean` |
 | autoConnect | By default as soon as the client library is instantiated it will connect to Ably. You can optionally set this to false and explicitly connect to Ably when require using the [`connect`](/docs/api/realtime-sdk/connection#connect) method<br />**Default:** true | `Boolean` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
 | defaultTokenParams | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests | [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | disconnectedRetryTimeout | When the connection enters the `DISCONNECTED` state, after this delay in milliseconds, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Default:** 15,000ms | `Integer` |
 | suspendedRetryTimeout | When the connection enters the `SUSPENDED` state, after this delay in milliseconds, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Default:** 30,000ms | `Integer` |
@@ -2124,17 +2124,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Property | Description | Type |
 |----------|-------------|------|
-| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| Token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls | `Callable` |
+| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| Token | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls | `Callable` |
 | AuthUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server | `String` |
 | AuthMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />**Default:** `GET` | `String` |
 | AuthHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response | `Map<String, String>` |
 | AuthParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response | `Map<String, String>` |
-| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | Tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />**Default:** true | `Boolean` |
-| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| UseTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
+| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| UseTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients)<br />**Default:** false | `Boolean` |
 | Endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** null | `String` |
 | Environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details<br />**Default:** null | `String` |
 | IdempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />**Default:** true | `Boolean` |
@@ -2144,7 +2144,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | QueueMessages | If false, this disables the default behavior whereby the library queues messages on a connection in the disconnected or connecting states. The default behavior allows applications to submit messages immediately upon instancing the library without having to wait for the connection to be established. Applications may use this option to disable queueing if they wish to have application-level control over the queueing under those conditions<br />**Default:** true | `Boolean` |
 | EchoMessages | If false, prevents messages originating from this connection being echoed back on the same connection<br />**Default:** true | `Boolean` |
 | AutoConnect | By default as soon as the client library is instantiated it will connect to Ably. You can optionally set this to false and explicitly connect to Ably when require using the [`connect`](/docs/api/realtime-sdk/connection#connect) method<br />**Default:** true | `Boolean` |
-| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
+| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/realtime-sdk/authentication#request-token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request<br />**Default:** false | `Boolean` |
 | DefaultTokenParams | When a [TokenParams](/docs/api/realtime-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new Ably Tokens or Ably TokenRequests | [`TokenParams`](/docs/api/realtime-sdk/types#token-params) |
 | DisconnectedRetryTimeout | When the connection enters the `DISCONNECTED` state, after this delay in milliseconds, if the state is still `DISCONNECTED`, the client library will attempt to reconnect automatically<br />**Default:** 15,000ms | `Integer` |
 | SuspendedRetryTimeout | When the connection enters the `SUSPENDED` state, after this delay in milliseconds, if the state is still `SUSPENDED`, the client library will attempt to reconnect automatically<br />**Default:** 30,000ms | `Integer` |
@@ -3283,25 +3283,25 @@ Mark the `Deferrable` as succeeded and trigger all callbacks. See the [EventMach
 
 <If lang="javascript,nodejs">
 
-`TokenParams` is a plain JavaScript object and is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following attributes can be defined on the object:
+`TokenParams` is a plain JavaScript object and is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following attributes can be defined on the object:
 
 </If>
 
 <If lang="ruby">
 
-`TokenParams` is a Hash object and is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following key symbol values can be added to the Hash:
+`TokenParams` is a Hash object and is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following key symbol values can be added to the Hash:
 
 </If>
 
 <If lang="java,csharp">
 
-`TokenParams` is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
+`TokenParams` is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
 
 </If>
 
 <If lang="objc,swift">
 
-`ARTTokenParams` is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
+`ARTTokenParams` is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
 
 </If>
 
@@ -3309,8 +3309,8 @@ Mark the `Deferrable` as succeeded and trigger all callbacks. See the [EventMach
 
 | Property | Description | Type |
 |----------|-------------|------|
-| <If lang="javascript,nodejs,java,objc,swift,flutter">capability</If><If lang="csharp,go">Capability</If><If lang="ruby">:capability</If> | JSON stringified capability of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) request is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. [Find our more about how to use capabilities to manage access privileges for clients](/docs/auth/capabilities). | <If lang="javascript,nodejs,java,objc,swift,ruby,flutter,go">`String`</If><If lang="csharp">`Capability`</If> |
-| <If lang="javascript,nodejs,java,objc,swift,flutter">clientId</If><If lang="csharp,go">ClientId</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,java,objc,swift,flutter">`clientId`</If><If lang="ruby">`:client_id`</If><If lang="csharp,go">`ClientId`</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,java,objc,swift,flutter">`clientId`</If><If lang="ruby">`:client_id`</If><If lang="csharp,go">`ClientId`</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,java,objc,swift,flutter">`clientId`</If><If lang="ruby">`:client_id`</If><If lang="csharp,go">`ClientId`</If> specified here conflicts with the <If lang="javascript,nodejs,java,objc,swift,flutter">`clientId`</If><If lang="ruby">`:client_id`</If><If lang="csharp,go">`ClientId`</If> implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
+| <If lang="javascript,nodejs,java,objc,swift,flutter">capability</If><If lang="csharp,go">Capability</If><If lang="ruby">:capability</If> | JSON stringified capability of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) request is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. [Find our more about how to use capabilities to manage access privileges for clients](/docs/platform/auth/capabilities). | <If lang="javascript,nodejs,java,objc,swift,ruby,flutter,go">`String`</If><If lang="csharp">`Capability`</If> |
+| <If lang="javascript,nodejs,java,objc,swift,flutter">clientId</If><If lang="csharp,go">ClientId</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,java,objc,swift,flutter">`clientId`</If><If lang="ruby">`:client_id`</If><If lang="csharp,go">`ClientId`</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,java,objc,swift,flutter">`clientId`</If><If lang="ruby">`:client_id`</If><If lang="csharp,go">`ClientId`</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,java,objc,swift,flutter">`clientId`</If><If lang="ruby">`:client_id`</If><If lang="csharp,go">`ClientId`</If> specified here conflicts with the <If lang="javascript,nodejs,java,objc,swift,flutter">`clientId`</If><If lang="ruby">`:client_id`</If><If lang="csharp,go">`ClientId`</If> implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
 | <If lang="javascript,nodejs,java,objc,swift,flutter">nonce</If><If lang="csharp,go">Nonce</If><If lang="ruby">:nonce</If> | An optional opaque nonce string of at least 16 characters to ensure uniqueness of this request. Any subsequent request using the same nonce will be rejected. | `String` |
 | <If lang="javascript,nodejs,java,objc,swift,flutter">timestamp</If><If lang="csharp,go">Timestamp</If><If lang="ruby">:timestamp</If> | <If lang="javascript,nodejs,java,flutter">The timestamp (in milliseconds since the epoch)</If><If lang="ruby,objc,swift,csharp">The timestamp</If> of this request. `timestamp`, in conjunction with the `nonce`, is used to prevent requests for [Ably Token](/docs/api/realtime-sdk/authentication#token-details) from being replayed. | <If lang="javascript,nodejs,flutter">`Integer`</If><If lang="java">`Long Integer`</If><If lang="ruby">`Time`</If><If lang="objc,swift">`NSDate`</If><If lang="csharp">`DateTimeOffset`</If> |
 | <If lang="javascript,nodejs,java,objc,swift,flutter">ttl</If><If lang="csharp,go">Ttl</If><If lang="ruby">:ttl</If> | _1 hour_ Requested time to live for the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) being created <If lang="javascript,nodejs,java,flutter">in milliseconds</If><If lang="ruby">in seconds</If><If lang="objc,swift">as a `NSTimeInterval`</If><If lang="csharp,go">as a `TimeSpan`</If>. When omitted, the Ably REST API default of 60 minutes is applied by Ably | <If lang="javascript,nodejs,flutter">`Integer` (milliseconds)</If><If lang="ruby">`Integer` (seconds)</If><If lang="objc,swift">`NSTimeInterval`</If><If lang="java">`Long Integer`</If><If lang="csharp">`TimeSpan`</If> |
diff --git a/src/pages/docs/api/rest-api.mdx b/src/pages/docs/api/rest-api.mdx
index 055ebf3b15..3a609933de 100644
--- a/src/pages/docs/api/rest-api.mdx
+++ b/src/pages/docs/api/rest-api.mdx
@@ -295,7 +295,7 @@ Envelope responses always are always made with a 200 status code; the status of
 
 ## Authentication <a id="authentication" />
 
-To understand the REST API it is easiest first to understand the various authentication methods that Ably supports. For a detailed explanation, view the [Authentication documentation](/docs/auth).
+To understand the REST API it is easiest first to understand the various authentication methods that Ably supports. For a detailed explanation, view the [Authentication documentation](/docs/platform/auth).
 
 Clients can access Ably, whether using REST or the Realtime service, by two methods:
 
@@ -343,7 +343,7 @@ curl https://main.realtime.ably.net/channels/rest-example/messages \
 
 ### Token Authentication <a id="token-authentication" />
 
-**Token Authentication** uses an Ably-compatible token to authenticate with Ably without sharing a private API key. This can be an [Ably Token](/docs/api/rest-sdk/authentication#tokens) obtained via the REST API [`requestToken`](#request-token) endpoint, an [Ably JWT](/docs/api/rest-sdk/authentication#ably-jwt) signed by your API key, or an [External JWT](https://jwt.io) object [with an embedded Ably-compatible token](/docs/auth/token#embedded). Tokens are authentication credentials that are short-lived, and therefore they may more readily be distributed to clients where there is a risk of compromise. Tokens may also be issued with a particular scope - such as a limited set of [access rights or capabilities](/docs/auth/capabilities) or being limited to use by a specific [`clientId` identity](#identified-clients) - and therefore token-based authentication provides the flexibility to implement access and identity control policies in the application. See the [Token Authentication documentation](/docs/auth/token) for more details.
+**Token Authentication** uses an Ably-compatible token to authenticate with Ably without sharing a private API key. This can be an [Ably Token](/docs/api/rest-sdk/authentication#tokens) obtained via the REST API [`requestToken`](#request-token) endpoint, an [Ably JWT](/docs/api/rest-sdk/authentication#ably-jwt) signed by your API key, or an [External JWT](https://jwt.io) object [with an embedded Ably-compatible token](/docs/platform/auth/token#embedded). Tokens are authentication credentials that are short-lived, and therefore they may more readily be distributed to clients where there is a risk of compromise. Tokens may also be issued with a particular scope - such as a limited set of [access rights or capabilities](/docs/platform/auth/capabilities) or being limited to use by a specific [`clientId` identity](#identified-clients) - and therefore token-based authentication provides the flexibility to implement access and identity control policies in the application. See the [Token Authentication documentation](/docs/platform/auth/token) for more details.
 
 The construction of an Ably [`TokenRequest`](/docs/api/token-request-spec) is described in the [Authentication Ably TokenRequest spec documentation](/docs/api/token-request-spec). The resulting `token response` object contains the token properties as defined in [Ably TokenRequest spec](/docs/api/token-request-spec).
 
@@ -740,7 +740,7 @@ curl -X PATCH https://main.realtime.ably.net/channels/rest-example/messages/0182
 
 ##### Capabilities
 
-- `message-update-own` := Can update or append to your own messages (messages where the original publisher's `clientId` matches the updater's `clientId`, where both are [identified](/docs/auth/identified-clients))
+- `message-update-own` := Can update or append to your own messages (messages where the original publisher's `clientId` matches the updater's `clientId`, where both are [identified](/docs/platform/auth/identified-clients))
 - `message-update-any` := Can update or append to any message on the channel
 - `message-delete-own` := Can delete your own messages
 - `message-delete-any` := Can delete any message on the channel
@@ -1733,7 +1733,7 @@ A successful request returns a [paginated response](#pagination) of:
 
 ### Publish directly to specific recipients <a id="push-publish" />
 
-Convenience endpoint to deliver a push notification payload to a single device or set of devices identified by their [client identifier](/docs/auth/identified-clients).
+Convenience endpoint to deliver a push notification payload to a single device or set of devices identified by their [client identifier](/docs/platform/auth/identified-clients).
 
 If you want to send a push notification to subscribed clients without knowing about recipient devices' details, we recommend you look at [registering devices for push](#post-device-registration), then [subscribe them to channels](#post-channel-subscription), and then [send messages to the channels with push payloads](#message-extras-push).
 
@@ -1995,7 +1995,7 @@ The request body has the following properties:
 
 | Property | Description |
 |----------|-------------|
-| targets | An array of [target specifier](/docs/auth/revocation#target-specifiers) strings. |
+| targets | An array of [target specifier](/docs/platform/auth/revocation#target-specifiers) strings. |
 | issuedBefore | Optional number (Unix timestamp in milliseconds); if not specified it is set to the current time. The token revocation only applies to tokens issued before this timestamp. A request with an `issuedBefore` in the future, or more than an hour in the past will be rejected. |
 | allowReauthMargin | The `allowReauthMargin` bool permits a token renewal cycle to take place without needing established connections to be dropped, by postponing enforcement to 30 seconds in the future, and sending any existing connections a hint to obtain (and upgrade the connection to use) a new token. It defaults to `false`, meaning that the effect is near-immediate. |
 
@@ -2026,7 +2026,7 @@ The response is comparable to that of [Batch publish](#batch). If some tokens ca
 
 ##### See also
 
-See the [token revocation documentation](/docs/auth/revocation) for further details.
+See the [token revocation documentation](/docs/platform/auth/revocation) for further details.
 
 ## Application routes <a id="application" />
 
@@ -2079,7 +2079,7 @@ Stats records contain a hierarchy of elements relating to messages, connections
 
 Ably's message statistics categorize unsuccessful message delivery into two distinct types: refused and failed messages.
 
-**Refused messages** are actively rejected by Ably's system. The most common cause is breaching a [rate limit](/docs/platform/pricing/limits), though refusals can also occur due to malformed message structure, insufficient [channel permissions](/docs/auth/capabilities), or other request defects.
+**Refused messages** are actively rejected by Ably's system. The most common cause is breaching a [rate limit](/docs/platform/pricing/limits), though refusals can also occur due to malformed message structure, insufficient [channel permissions](/docs/platform/auth/capabilities), or other request defects.
 
 **Failed messages** represent delivery attempts that were unsuccessful for reasons other than active rejection by Ably. This category includes internal service issues and rejections from external systems. In the case of [Integrations](/docs/platform/integrations) or [Push Notifications](/docs/push), when an external target rejects a message, it appears in statistics as a failed message.
 
diff --git a/src/pages/docs/api/rest-sdk.mdx b/src/pages/docs/api/rest-sdk.mdx
index 10e43ecc7c..e20e6a291f 100644
--- a/src/pages/docs/api/rest-sdk.mdx
+++ b/src/pages/docs/api/rest-sdk.mdx
@@ -10,7 +10,7 @@ redirect_from:
 
 ## Constructor <a id="constructor" />
 
-The Ably REST library constructor is overloaded allowing it to be instantiated using a [`ClientOptions`](#client-options) object, or more simply using a string containing an [API key](/docs/auth/basic) or [Token](/docs/auth/token).
+The Ably REST library constructor is overloaded allowing it to be instantiated using a [`ClientOptions`](#client-options) object, or more simply using a string containing an [API key](/docs/platform/auth/basic) or [Token](/docs/platform/auth/token).
 
 <If lang="javascript,nodejs">
 
@@ -153,11 +153,11 @@ The REST constructor is used to instantiate the library. The REST library may be
 
 ### Authentication <a id="authentication" />
 
-The REST library needs to have credentials to be able to authenticate with the Ably service. Ably supports both Basic and Token based authentication schemes. Read more on [authentication](/docs/auth).
+The REST library needs to have credentials to be able to authenticate with the Ably service. Ably supports both Basic and Token based authentication schemes. Read more on [authentication](/docs/platform/auth).
 
 #### Basic Authentication
 
-A private API key string for <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift">[`ClientOptions#key`](#client-options)</If><If lang="csharp,go">[`ClientOptions#Key`](#client-options)</If> or the constructor, as obtained from the [application dashboard](https://ably.com/dashboard), is required for [Basic Authentication](/docs/auth/basic). Use this option if you wish to use [Basic authentication](/docs/auth/basic), or if you want to be able to [request Ably Tokens](/docs/auth/token) without needing to defer to a separate entity to sign Ably TokenRequests. Note that initializing the library with a <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift">`key`</If><If lang="csharp,go">`Key`</If> does not necessarily mean that the library will use Basic auth; using the private key it is also able to create and sign Ably TokenRequests and use token authentication when necessary.
+A private API key string for <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift">[`ClientOptions#key`](#client-options)</If><If lang="csharp,go">[`ClientOptions#Key`](#client-options)</If> or the constructor, as obtained from the [application dashboard](https://ably.com/dashboard), is required for [Basic Authentication](/docs/platform/auth/basic). Use this option if you wish to use [Basic authentication](/docs/platform/auth/basic), or if you want to be able to [request Ably Tokens](/docs/platform/auth/token) without needing to defer to a separate entity to sign Ably TokenRequests. Note that initializing the library with a <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift">`key`</If><If lang="csharp,go">`Key`</If> does not necessarily mean that the library will use Basic auth; using the private key it is also able to create and sign Ably TokenRequests and use token authentication when necessary.
 
 #### Token Authentication
 
@@ -165,7 +165,7 @@ The <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift">[`Clien
 
 Since tokens are short-lived, it is rarely sufficient to start with a token without the means for refreshing it. The <If lang="javascript,nodejs,flutter,java,objc,swift">[`authUrl` and `authCallback` options](#client-options)</If><If lang="ruby">[`:auth_url` and `:auth_callback` options](#client-options)</If><If lang="python">[`auth_url` and `auth_callback` options](#client-options)</If><If lang="csharp,go">[`AuthUrl` and `AuthCallback` options](#client-options)</If> are provided to allow a user of the library to provide new Ably-compatible tokens or Ably TokenRequests to the library as required; using these options allows the library to be instantiated without a <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift">`key` or `token`</If><If lang="csharp,go">`Key` or `Token`</If>, and an initial token will be obtained automatically when required.
 
-Read more on [authentication](/docs/auth).
+Read more on [authentication](/docs/platform/auth).
 
 <If lang="objc,swift">
 
@@ -686,17 +686,17 @@ Returns a promise. On success, the promise is fulfilled with a [`BatchResult`](#
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| <If lang="javascript,nodejs,java,objc,php,python,swift">key</If><If lang="go">Key</If><If lang="ruby">:key</If> | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| <If lang="javascript,nodejs,java,objc,php,python,swift">token</If><If lang="go">Token</If><If lang="ruby">:token</If> | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,java,objc,php,python,swift">`token`</If><If lang="go">`Token`</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,swift">`authUrl`</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> or <If lang="javascript,nodejs,java,objc,php,swift">`authCallback`</If><If lang="go">`AuthCallback`</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| <If lang="javascript,nodejs,java,objc,php,swift">authCallback</If><If lang="go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If> | A <If lang="javascript,nodejs,flutter,java,objc,php,python,swift,go,ruby">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="python">callable (eg a lambda)</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If> |
+| <If lang="javascript,nodejs,java,objc,php,python,swift">key</If><If lang="go">Key</If><If lang="ruby">:key</If> | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| <If lang="javascript,nodejs,java,objc,php,python,swift">token</If><If lang="go">Token</If><If lang="ruby">:token</If> | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,java,objc,php,python,swift">`token`</If><If lang="go">`Token`</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,swift">`authUrl`</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> or <If lang="javascript,nodejs,java,objc,php,swift">`authCallback`</If><If lang="go">`AuthCallback`</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| <If lang="javascript,nodejs,java,objc,php,swift">authCallback</If><If lang="go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If> | A <If lang="javascript,nodejs,flutter,java,objc,php,python,swift,go,ruby">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="python">callable (eg a lambda)</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authUrl</If><If lang="go">AuthUrl</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,go">`String`</If><If lang="swift,objc">`NSURL`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authMethod</If><If lang="go">AuthMethod</If><If lang="python">auth_method</If><If lang="ruby">:auth_method</If> | The HTTP verb to use for the request, either <If lang="javascript,nodejs,java,objc,php,python,swift,go">`GET`</If><If lang="ruby">`:get`</If> or <If lang="javascript,nodejs,java,objc,php,python,swift,go">`POST`</If><If lang="ruby">`:post`</If><br />_default: <If lang="javascript,nodejs,java,objc,php,python,swift,go">`GET`</If><If lang="ruby">`:get`</If>_ | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`String`</If><If lang="ruby">`Symbol`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authHeaders</If><If lang="go">AuthHeaders</If><If lang="python">auth_headers</If><If lang="ruby">:auth_headers</If> | A set of key value pair headers to be added to any request made to the <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift,go">`authUrl`</If>. Useful when an application requires these to be added to validate the request or implement the response. <If lang="javascript">If the `authHeaders` object contains an `authorization` key, then `withCredentials` will be set on the xhr request.</If> | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`Object`</If><If lang="python">`Dict`</If><If lang="ruby">`Hash`</If><If lang="php">`Associative Array`</If><If lang="java">`Param []`</If><If lang="flutter">`Map<String, String>`</If> |
 | <If lang="javascript,nodejs,java,objc,php,,swift">authParams</If><If lang="go">AuthParams</If><If lang="ruby">:auth_params</If><If lang="python">auth_params</If> | A set of key value pair params to be added to any request made to the <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift,go">`authUrl`</If>. When the <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift,go">`authMethod`</If><If lang="go">`AuthMethod`</If> is `GET`, query params are added to the URL, whereas when <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift,go">`authMethod`</If><If lang="go">`AuthMethod`</If> is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`Object`</If><If lang="ruby">`Hash`</If><If lang="php">`Associative Array`</If><If lang="java">`Param[]`</If><If lang="objc">`NSArray<NSURLQueryItem *>`</If><If lang="swift">`[NSURLQueryItem]/Array<NSURLQueryItem>`</If><If lang="flutter">`Map<String, String>`</If> |
-| <If lang="javascript,nodejs,java,objc,php,swift">tokenDetails</If><If lang="go">TokenDetails</If><If lang="python">token_details</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,python,swift">`authUrl`</If><If lang="go">`AuthUrl`</If><If lang="ruby">`:auth_url`</If><If lang="python">`auth_url`</If> or <If lang="javascript,nodejs,java,objc,php,python,swift">`authCallback`</If><If lang="go">AuthCallback</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| <If lang="javascript,nodejs,java,objc,php,swift">tokenDetails</If><If lang="go">TokenDetails</If><If lang="python">token_details</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,python,swift">`authUrl`</If><If lang="go">`AuthUrl`</If><If lang="ruby">`:auth_url`</If><If lang="python">`auth_url`</If> or <If lang="javascript,nodejs,java,objc,php,python,swift">`authCallback`</If><If lang="go">AuthCallback</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | <If lang="javascript,nodejs,java,objc,php,python,swift">tls</If><If lang="go">Tls</If><If lang="ruby">:tls</If> | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />_default: true_ | `Boolean` |
-| <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="go">ClientId</If><If lang="python">client_id</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If> specified here conflicts with the <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| <If lang="javascript,nodejs,java,objc,php,swift">useTokenAuth</If><If lang="go">UseTokenAuth</If><If lang="python">use_token_auth</If><If lang="ruby">:use_token_auth</If> | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a <If lang="ruby,python">`client_id`</If><If lang="javascript,nodejs,java,objc,php,python,swift,go">`clientId`</If> is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
+| <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="go">ClientId</If><If lang="python">client_id</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If> specified here conflicts with the <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| <If lang="javascript,nodejs,java,objc,php,swift">useTokenAuth</If><If lang="go">UseTokenAuth</If><If lang="python">use_token_auth</If><If lang="ruby">:use_token_auth</If> | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a <If lang="ruby,python">`client_id`</If><If lang="javascript,nodejs,java,objc,php,python,swift,go">`clientId`</If> is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
 | <If lang="javascript,nodejs,java,objc,php,python,swift">endpoint</If><If lang="go">Endpoint</If><If lang="ruby">:endpoint</If> | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: <If lang="javascript,nodejs,java,objc,php,python,swift,go">null</If><If lang="java">Null</If><If lang="python">None</If><If lang="ruby,objc,swift">nil</If>_ | `String` |
 | <If lang="javascript,nodejs,java,objc,php,python,swift">environment</If><If lang="go">Environment</If><If lang="ruby">:environment</If> | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: <If lang="javascript,nodejs,java,objc,php,python,swift,go">null</If><If lang="java">Null</If><If lang="python">None</If><If lang="ruby,objc,swift">nil</If>_ | `String` |
 | <If lang="javascript,nodejs,java,objc,php,python,swift">idempotentRestPublishing</If><If lang="go">IdempotentRestPublishing</If><If lang="ruby">:idempotent_rest_publishing</If> | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />_default: true_ | `Boolean` |
@@ -706,7 +706,7 @@ Returns a promise. On success, the promise is fulfilled with a [`BatchResult`](#
 | <If lang="javascript,nodejs,java,objc,php,swift">logHandler</If><If lang="python">log_handler</If> | A function to handle each line of the library's log output. If `logHandler` is not specified, `console.log` is used. | `Callable` |
 | transports | An optional array of transports to use, in descending order of preference. In the browser environment the available transports are: `web_socket`, `xhr_polling`. | `String[]` |
 | <If lang="javascript,nodejs,java,objc,php,swift">useBinaryProtocol</If><If lang="python">use_binary_protocol</If> | If set to true, will enable the binary protocol (MessagePack) if it is supported. It's disabled by default on browsers for performance considerations (browsers are optimized for decoding JSON). Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency)<br />_default: false_ | `Boolean` |
-| <If lang="javascript,nodejs,java,objc,php,swift">queryTime</If><If lang="go">QueryTime</If><If lang="ruby">:query_time</If><If lang="python">query_time</If> | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
+| <If lang="javascript,nodejs,java,objc,php,swift">queryTime</If><If lang="go">QueryTime</If><If lang="ruby">:query_time</If><If lang="python">query_time</If> | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
 | <If lang="javascript,nodejs,java,objc,php,swift">defaultTokenParams</If><If lang="python">default_token_params</If><If lang="ruby">:default_token_params</If><If lang="go">DefaultTokenParams</If> | When a [`TokenParams`](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably `TokenRequests`](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -716,17 +716,17 @@ Returns a promise. On success, the promise is fulfilled with a [`BatchResult`](#
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| Token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `Token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
+| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| Token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `Token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
 | AuthUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `String` |
 | AuthMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />_default: `GET`_ | `String` |
 | AuthHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. | `Object` |
 | AuthParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `AuthMethod` is `GET`, query params are added to the URL, whereas when `AuthMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | `Object` |
-| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | Tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />_default: true_ | `Boolean` |
-| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `ClientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `ClientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `ClientId` specified here conflicts with the `ClientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| UseTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `ClientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
+| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `ClientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `ClientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `ClientId` specified here conflicts with the `ClientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| UseTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `ClientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
 | Endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: null_ | `String` |
 | Environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: null_ | `String` |
 | IdempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />_default: true_ | `Boolean` |
@@ -734,7 +734,7 @@ Returns a promise. On success, the promise is fulfilled with a [`BatchResult`](#
 | transportParams | Optional. Can be used to pass in arbitrary connection parameters, such as [`heartbeatInterval`](/docs/connect#heartbeats) and [`remainPresentFor`](/docs/presence-occupancy/presence#unstable-connections) | `Object` |
 | LogLevel | A number controlling the verbosity of the log output of the library. Valid values are: 0 (no logs), 1 (errors only), 2 (errors plus connection and channel state changes), 3 (high-level debug output), and 4 (full debug output). | `Integer` |
 | UseBinaryProtocol | If set to true, will enable the binary protocol (MessagePack) if it is supported. It's disabled by default on browsers for performance considerations (browsers are optimized for decoding JSON). Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency)<br />_default: false_ | `Boolean` |
-| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
+| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
 | DefaultTokenParams | When a [`TokenParams`](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably `TokenRequests`](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -745,17 +745,17 @@ Returns a promise. On success, the promise is fulfilled with a [`BatchResult`](#
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| :key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| :token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `:auth_url` or `:auth_callback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| :auth_callback | A proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter) which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `Proc` |
+| :key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| :token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `:auth_url` or `:auth_callback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| :auth_callback | A proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter) which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `Proc` |
 | :auth_url | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `String` |
 | :auth_method | The HTTP verb to use for the request, either `:get` or `:post`<br />_default: `:get`_ | `Symbol` |
 | :auth_headers | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. | `Hash` |
 | :auth_params | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | `Hash` |
-| :token_details | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `:auth_url` or `:auth_callback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| :token_details | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `:auth_url` or `:auth_callback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | :tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />_default: true_ | `Boolean` |
-| :client_id | A client ID, used for identifying this client when publishing messages or for presence purposes. The `client_id` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `client_id` may also be implicit in a token used to instantiate the library; an error will be raised if a `client_id` specified here conflicts with the `client_id` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| :use_token_auth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `client_id` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
+| :client_id | A client ID, used for identifying this client when publishing messages or for presence purposes. The `client_id` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `client_id` may also be implicit in a token used to instantiate the library; an error will be raised if a `client_id` specified here conflicts with the `client_id` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| :use_token_auth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `client_id` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
 | :endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: nil_ | `String` |
 | :environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: nil_ | `String` |
 | :idempotent_rest_publishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />_default: true_ | `Boolean` |
@@ -764,7 +764,7 @@ Returns a promise. On success, the promise is fulfilled with a [`BatchResult`](#
 | :log_level | A number controlling the verbosity of the log output of the library. Valid values are: 0 (no logs), 1 (errors only), 2 (errors plus connection and channel state changes), 3 (high-level debug output), and 4 (full debug output). | `Integer` |
 | :logger | A Ruby [`Logger`](http://ruby-doc.org/stdlib-1.9.3/libdoc/logger/rdoc/Logger.html) compatible object to handle each line of log output. If `logger` is not specified, `STDOUT` is used. | `STDOUT Logger` |
 | :use_binary_protocol | If set to false, will forcibly disable the binary protocol (MessagePack). The binary protocol is used by default unless it is not supported. The default is true. Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency)<br />_default: true_ | `Boolean` |
-| :query_time | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
+| :query_time | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
 | :default_token_params | When a [`TokenParams`](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably `TokenRequests`](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 
@@ -775,24 +775,24 @@ Returns a promise. On success, the promise is fulfilled with a [`BatchResult`](#
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| <If lang="javascript,nodejs,java,objc,php,python,swift">key</If><If lang="go">Key</If><If lang="ruby">:key</If> | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| <If lang="javascript,nodejs,java,objc,php,python,swift">token</If><If lang="go">Token</If><If lang="ruby">:token</If> | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,java,objc,php,python,swift">`token`</If><If lang="go">`Token`</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,swift">`authUrl`</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> or <If lang="javascript,nodejs,java,objc,php,swift">`authCallback`</If><If lang="go">`AuthCallback`</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| <If lang="javascript,nodejs,java,objc,php,swift">authCallback</If><If lang="go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If> | A <If lang="javascript,nodejs,flutter,java,objc,php,python,swift,go,ruby">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="python">callable (eg a lambda)</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If> |
+| <If lang="javascript,nodejs,java,objc,php,python,swift">key</If><If lang="go">Key</If><If lang="ruby">:key</If> | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| <If lang="javascript,nodejs,java,objc,php,python,swift">token</If><If lang="go">Token</If><If lang="ruby">:token</If> | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,java,objc,php,python,swift">`token`</If><If lang="go">`Token`</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,swift">`authUrl`</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> or <If lang="javascript,nodejs,java,objc,php,swift">`authCallback`</If><If lang="go">`AuthCallback`</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| <If lang="javascript,nodejs,java,objc,php,swift">authCallback</If><If lang="go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If> | A <If lang="javascript,nodejs,flutter,java,objc,php,python,swift,go,ruby">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="python">callable (eg a lambda)</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authUrl</If><If lang="go">AuthUrl</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,go">`String`</If><If lang="swift,objc">`NSURL`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authMethod</If><If lang="go">AuthMethod</If><If lang="python">auth_method</If><If lang="ruby">:auth_method</If> | The HTTP verb to use for the request, either <If lang="javascript,nodejs,java,objc,php,python,swift,go">`GET`</If><If lang="ruby">`:get`</If> or <If lang="javascript,nodejs,java,objc,php,python,swift,go">`POST`</If><If lang="ruby">`:post`</If><br />_default: <If lang="javascript,nodejs,java,objc,php,python,swift,go">`GET`</If><If lang="ruby">`:get`</If>_ | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`String`</If><If lang="ruby">`Symbol`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authHeaders</If><If lang="go">AuthHeaders</If><If lang="python">auth_headers</If><If lang="ruby">:auth_headers</If> | A set of key value pair headers to be added to any request made to the <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift,go">`authUrl`</If>. Useful when an application requires these to be added to validate the request or implement the response. <If lang="javascript">If the `authHeaders` object contains an `authorization` key, then `withCredentials` will be set on the xhr request.</If> | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`Object`</If><If lang="python">`Dict`</If><If lang="ruby">`Hash`</If><If lang="php">`Associative Array`</If><If lang="java">`Param []`</If><If lang="flutter">`Map<String, String>`</If> |
 | <If lang="javascript,nodejs,java,objc,php,,swift">authParams</If><If lang="go">AuthParams</If><If lang="ruby">:auth_params</If><If lang="python">auth_params</If> | A set of key value pair params to be added to any request made to the <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift,go">`authUrl`</If>. When the <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift,go">`authMethod`</If><If lang="go">`AuthMethod`</If> is `GET`, query params are added to the URL, whereas when <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift,go">`authMethod`</If><If lang="go">`AuthMethod`</If> is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`Object`</If><If lang="ruby">`Hash`</If><If lang="php">`Associative Array`</If><If lang="java">`Param[]`</If><If lang="objc">`NSArray<NSURLQueryItem *>`</If><If lang="swift">`[NSURLQueryItem]/Array<NSURLQueryItem>`</If><If lang="flutter">`Map<String, String>`</If> |
-| <If lang="javascript,nodejs,java,objc,php,swift">tokenDetails</If><If lang="go">TokenDetails</If><If lang="python">token_details</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,python,swift">`authUrl`</If><If lang="go">`AuthUrl`</If><If lang="ruby">`:auth_url`</If><If lang="python">`auth_url`</If> or <If lang="javascript,nodejs,java,objc,php,python,swift">`authCallback`</If><If lang="go">AuthCallback</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| <If lang="javascript,nodejs,java,objc,php,swift">tokenDetails</If><If lang="go">TokenDetails</If><If lang="python">token_details</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,python,swift">`authUrl`</If><If lang="go">`AuthUrl`</If><If lang="ruby">`:auth_url`</If><If lang="python">`auth_url`</If> or <If lang="javascript,nodejs,java,objc,php,python,swift">`authCallback`</If><If lang="go">AuthCallback</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | <If lang="javascript,nodejs,java,objc,php,python,swift">tls</If><If lang="go">Tls</If><If lang="ruby">:tls</If> | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />_default: true_ | `Boolean` |
-| <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="go">ClientId</If><If lang="python">client_id</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If> specified here conflicts with the <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| <If lang="javascript,nodejs,java,objc,php,swift">useTokenAuth</If><If lang="go">UseTokenAuth</If><If lang="python">use_token_auth</If><If lang="ruby">:use_token_auth</If> | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a <If lang="ruby,python">`client_id`</If><If lang="javascript,nodejs,java,objc,php,python,swift,go">`clientId`</If> is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
+| <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="go">ClientId</If><If lang="python">client_id</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If> specified here conflicts with the <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| <If lang="javascript,nodejs,java,objc,php,swift">useTokenAuth</If><If lang="go">UseTokenAuth</If><If lang="python">use_token_auth</If><If lang="ruby">:use_token_auth</If> | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a <If lang="ruby,python">`client_id`</If><If lang="javascript,nodejs,java,objc,php,python,swift,go">`clientId`</If> is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
 | <If lang="javascript,nodejs,java,objc,php,python,swift">endpoint</If><If lang="go">Endpoint</If><If lang="ruby">:endpoint</If> | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: <If lang="javascript,nodejs,java,objc,php,python,swift,go">null</If><If lang="java">Null</If><If lang="python">None</If><If lang="ruby,objc,swift">nil</If>_ | `String` |
 | <If lang="javascript,nodejs,java,objc,php,python,swift">environment</If><If lang="go">Environment</If><If lang="ruby">:environment</If> | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: <If lang="javascript,nodejs,java,objc,php,python,swift,go">null</If><If lang="java">Null</If><If lang="python">None</If><If lang="ruby,objc,swift">nil</If>_ | `String` |
 | <If lang="javascript,nodejs,java,objc,php,python,swift">idempotentRestPublishing</If><If lang="go">IdempotentRestPublishing</If><If lang="ruby">:idempotent_rest_publishing</If> | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />_default: true_ | `Boolean` |
 | <If lang="javascript,nodejs,java,objc,php,swift">fallbackHosts</If><If lang="go">FallbackHosts</If><If lang="python">fallback_hosts</If><If lang="ruby">:fallback_hosts</If> | An array of fallback hosts to be used in the case of an error necessitating the use of an alternative host. When a custom environment is specified, the [fallback host functionality](https://faqs.ably.com/routing-around-network-and-dns-issues) is disabled. If your customer success manager has provided you with a set of custom fallback hosts, please specify them here.<br />_default: `[a.ably-realtime.com, b.ably-realtime.com, c.ably-realtime.com, d.ably-realtime.com, e.ably-realtime.com]`_ | `String []` |
 | <If lang="javascript,nodejs,java,objc,php,swift">transportParams</If><If lang="python">transport_params</If><If lang="ruby">:transport_params</If> | Optional. Can be used to pass in arbitrary connection parameters, such as [`heartbeatInterval`](/docs/connect#heartbeats) and [`remainPresentFor`](/docs/presence-occupancy/presence#unstable-connections) | <If lang="javascript,nodejs,java,objc,php,swift,go">`Object`</If><If lang="python">`Dict`</If><If lang="ruby">`Hash`</If><If lang="php">`Associative Array`</If><If lang="java">`Param []`</If><If lang="flutter">`Map<String, String>`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">useBinaryProtocol</If><If lang="python">use_binary_protocol</If> | If set to true, will enable the binary protocol (MessagePack) if it is supported. It's disabled by default on browsers for performance considerations (browsers are optimized for decoding JSON). Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency)<br />_default: false_ | `Boolean` |
-| <If lang="javascript,nodejs,java,objc,php,swift">queryTime</If><If lang="go">QueryTime</If><If lang="ruby">:query_time</If><If lang="python">query_time</If> | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
+| <If lang="javascript,nodejs,java,objc,php,swift">queryTime</If><If lang="go">QueryTime</If><If lang="ruby">:query_time</If><If lang="python">query_time</If> | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
 | <If lang="javascript,nodejs,java,objc,php,swift">defaultTokenParams</If><If lang="python">default_token_params</If><If lang="ruby">:default_token_params</If><If lang="go">DefaultTokenParams</If> | When a [`TokenParams`](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably `TokenRequests`](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -802,17 +802,17 @@ Returns a promise. On success, the promise is fulfilled with a [`BatchResult`](#
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| <If lang="javascript,nodejs,java,objc,php,python,swift">key</If><If lang="go">Key</If><If lang="ruby">:key</If> | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| <If lang="javascript,nodejs,java,objc,php,python,swift">token</If><If lang="go">Token</If><If lang="ruby">:token</If> | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,java,objc,php,python,swift">`token`</If><If lang="go">`Token`</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,swift">`authUrl`</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> or <If lang="javascript,nodejs,java,objc,php,swift">`authCallback`</If><If lang="go">`AuthCallback`</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| <If lang="javascript,nodejs,java,objc,php,swift">authCallback</If><If lang="go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If> | A <If lang="javascript,nodejs,flutter,java,objc,php,python,swift,go,ruby">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="python">callable (eg a lambda)</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If> |
+| <If lang="javascript,nodejs,java,objc,php,python,swift">key</If><If lang="go">Key</If><If lang="ruby">:key</If> | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| <If lang="javascript,nodejs,java,objc,php,python,swift">token</If><If lang="go">Token</If><If lang="ruby">:token</If> | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,java,objc,php,python,swift">`token`</If><If lang="go">`Token`</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,swift">`authUrl`</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> or <If lang="javascript,nodejs,java,objc,php,swift">`authCallback`</If><If lang="go">`AuthCallback`</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| <If lang="javascript,nodejs,java,objc,php,swift">authCallback</If><If lang="go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If> | A <If lang="javascript,nodejs,flutter,java,objc,php,python,swift,go,ruby">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="python">callable (eg a lambda)</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authUrl</If><If lang="go">AuthUrl</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,go">`String`</If><If lang="swift,objc">`NSURL`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authMethod</If><If lang="go">AuthMethod</If><If lang="python">auth_method</If><If lang="ruby">:auth_method</If> | The HTTP verb to use for the request, either <If lang="javascript,nodejs,java,objc,php,python,swift,go">`GET`</If><If lang="ruby">`:get`</If> or <If lang="javascript,nodejs,java,objc,php,python,swift,go">`POST`</If><If lang="ruby">`:post`</If><br />_default: <If lang="javascript,nodejs,java,objc,php,python,swift,go">`GET`</If><If lang="ruby">`:get`</If>_ | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`String`</If><If lang="ruby">`Symbol`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authHeaders</If><If lang="go">AuthHeaders</If><If lang="python">auth_headers</If><If lang="ruby">:auth_headers</If> | A set of key value pair headers to be added to any request made to the <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift,go">`authUrl`</If>. Useful when an application requires these to be added to validate the request or implement the response. <If lang="javascript">If the `authHeaders` object contains an `authorization` key, then `withCredentials` will be set on the xhr request.</If> | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`Object`</If><If lang="python">`Dict`</If><If lang="ruby">`Hash`</If><If lang="php">`Associative Array`</If><If lang="java">`Param []`</If><If lang="flutter">`Map<String, String>`</If> |
 | <If lang="javascript,nodejs,java,objc,php,,swift">authParams</If><If lang="go">AuthParams</If><If lang="ruby">:auth_params</If><If lang="python">auth_params</If> | A set of key value pair params to be added to any request made to the <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift,go">`authUrl`</If>. When the <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift,go">`authMethod`</If><If lang="go">`AuthMethod`</If> is `GET`, query params are added to the URL, whereas when <If lang="javascript,nodejs,flutter,java,objc,php,python,ruby,swift,go">`authMethod`</If><If lang="go">`AuthMethod`</If> is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | <If lang="javascript,nodejs,java,objc,php,python,swift,go">`Object`</If><If lang="ruby">`Hash`</If><If lang="php">`Associative Array`</If><If lang="java">`Param[]`</If><If lang="objc">`NSArray<NSURLQueryItem *>`</If><If lang="swift">`[NSURLQueryItem]/Array<NSURLQueryItem>`</If><If lang="flutter">`Map<String, String>`</If> |
-| <If lang="javascript,nodejs,java,objc,php,python,swift">tokenDetails</If><If lang="go">TokenDetails</If><If lang="python">token_details</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,python,swift">`authUrl`</If><If lang="go">`AuthUrl`</If><If lang="ruby">`:auth_url`</If><If lang="python">`auth_url`</If> or <If lang="javascript,nodejs,java,objc,php,python,swift">`authCallback`</If><If lang="go">AuthCallback</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| <If lang="javascript,nodejs,java,objc,php,python,swift">tokenDetails</If><If lang="go">TokenDetails</If><If lang="python">token_details</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,python,swift">`authUrl`</If><If lang="go">`AuthUrl`</If><If lang="ruby">`:auth_url`</If><If lang="python">`auth_url`</If> or <If lang="javascript,nodejs,java,objc,php,python,swift">`authCallback`</If><If lang="go">AuthCallback</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | <If lang="javascript,nodejs,java,objc,php,python,swift">tls</If><If lang="go">Tls</If><If lang="ruby">:tls</If> | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />_default: true_ | `Boolean` |
-| <If lang="javascript,nodejs,java,objc,php,python,swift">clientId</If><If lang="go">ClientId</If><If lang="python">client_id</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If> specified here conflicts with the <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| <If lang="javascript,nodejs,java,objc,php,python,swift">useTokenAuth</If><If lang="go">UseTokenAuth</If><If lang="python">use_token_auth</If><If lang="ruby">:use_token_auth</If> | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a <If lang="ruby,python">`client_id`</If><If lang="javascript,nodejs,java,objc,php,python,swift,go">`clientId`</If> is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
+| <If lang="javascript,nodejs,java,objc,php,python,swift">clientId</If><If lang="go">ClientId</If><If lang="python">client_id</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If> specified here conflicts with the <If lang="javascript,nodejs,java,objc,php,python,swift">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="go">`ClientId`</If> implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| <If lang="javascript,nodejs,java,objc,php,python,swift">useTokenAuth</If><If lang="go">UseTokenAuth</If><If lang="python">use_token_auth</If><If lang="ruby">:use_token_auth</If> | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a <If lang="ruby,python">`client_id`</If><If lang="javascript,nodejs,java,objc,php,python,swift,go">`clientId`</If> is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
 | <If lang="javascript,nodejs,java,objc,php,python,swift">endpoint</If><If lang="go">Endpoint</If><If lang="ruby">:endpoint</If> | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: <If lang="javascript,nodejs,java,objc,php,python,swift,go">null</If><If lang="java">Null</If><If lang="python">None</If><If lang="ruby,objc,swift">nil</If>_ | `String` |
 | <If lang="javascript,nodejs,java,objc,php,python,swift">environment</If><If lang="go">Environment</If><If lang="ruby">:environment</If> | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: <If lang="javascript,nodejs,java,objc,php,python,swift,go">null</If><If lang="java">Null</If><If lang="python">None</If><If lang="ruby,objc,swift">nil</If>_ | `String` |
 | <If lang="javascript,nodejs,java,objc,php,python,swift">idempotentRestPublishing</If><If lang="go">IdempotentRestPublishing</If><If lang="ruby">:idempotent_rest_publishing</If> | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />_default: true_ | `Boolean` |
@@ -821,7 +821,7 @@ Returns a promise. On success, the promise is fulfilled with a [`BatchResult`](#
 | <If lang="javascript,nodejs,java,objc,php,swift">logLevel</If><If lang="python">log_level</If> | A number controlling the verbosity of the log output of the library. Valid values are: 0 (no logs), 1 (errors only), 2 (errors plus connection and channel state changes), 3 (high-level debug output), and 4 (full debug output). | `Integer` |
 | <If lang="javascript,nodejs,java,objc,php,swift">logHandler</If><If lang="python">log_handler</If> | A function to handle each line of the library's log output. If `logHandler` is not specified, `console.log` is used. | `Callable` |
 | <If lang="javascript,nodejs,java,objc,php,swift">useBinaryProtocol</If><If lang="python">use_binary_protocol</If> | If set to true, will enable the binary protocol (MessagePack) if it is supported. It's disabled by default on browsers for performance considerations (browsers are optimized for decoding JSON). Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency)<br />_default: false_ | `Boolean` |
-| <If lang="javascript,nodejs,java,objc,php,python,swift">queryTime</If><If lang="go">QueryTime</If><If lang="ruby">:query_time</If><If lang="python">query_time</If> | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
+| <If lang="javascript,nodejs,java,objc,php,python,swift">queryTime</If><If lang="go">QueryTime</If><If lang="ruby">:query_time</If><If lang="python">query_time</If> | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
 | <If lang="javascript,nodejs,java,objc,php,swift">defaultTokenParams</If><If lang="python">default_token_params</If><If lang="ruby">:default_token_params</If><If lang="go">DefaultTokenParams</If> | When a [`TokenParams`](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably `TokenRequests`](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -831,24 +831,24 @@ Returns a promise. On success, the promise is fulfilled with a [`BatchResult`](#
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `String` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />_default: `GET`_ | `String` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. | `Map<String, String>` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | `Map<String, String>` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />_default: true_ | `Boolean` |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: null_ | `String` |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: null_ | `String` |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />_default: true_ | `Boolean` |
 | fallbackHosts | An array of fallback hosts to be used in the case of an error necessitating the use of an alternative host. When a custom environment is specified, the [fallback host functionality](https://faqs.ably.com/routing-around-network-and-dns-issues) is disabled. If your customer success manager has provided you with a set of custom fallback hosts, please specify them here.<br />_default: `[a.ably-realtime.com, b.ably-realtime.com, c.ably-realtime.com, d.ably-realtime.com, e.ably-realtime.com]`_ | `String []` |
 | transportParams | Optional. Can be used to pass in arbitrary connection parameters, such as [`heartbeatInterval`](/docs/connect#heartbeats) and [`remainPresentFor`](/docs/presence-occupancy/presence#unstable-connections) | `Map<String, String>` |
 | useBinaryProtocol | If set to true, will enable the binary protocol (MessagePack) if it is supported. It's disabled by default on browsers for performance considerations (browsers are optimized for decoding JSON). Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency)<br />_default: false_ | `Boolean` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
 | defaultTokenParams | When a [`TokenParams`](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably `TokenRequests`](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -860,17 +860,17 @@ Returns a promise. On success, the promise is fulfilled with a [`BatchResult`](#
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| Token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `Token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `Func<TokenParams, Task<object>>` |
+| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| Token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `Token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `Func<TokenParams, Task<object>>` |
 | AuthUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `Uri` |
 | AuthMethod | The HTTP verb to use for the request, either `GET` or `POST`<br />_default: `GET`_ | `HttpMethod` |
 | AuthHeaders | A set of key value pair headers to be added to any request made to the `AuthUrl`. Useful when an application requires these to be added to validate the request or implement the response. | `Dictionary<string, string>` |
 | AuthParams | A set of key value pair params to be added to any request made to the `AuthUrl`. When the `AuthMethod` is `GET`, query params are added to the URL, whereas when `AuthMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | `Dictionary<string, string>` |
-| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | Tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls)<br />_default: true_ | `Boolean` |
-| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `ClientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `ClientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `ClientId` specified here conflicts with the `ClientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| UseTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
+| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `ClientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `ClientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `ClientId` specified here conflicts with the `ClientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| UseTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients).<br />_default: false_ | `Boolean` |
 | Endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: null_ | `String` |
 | Environment | Deprecated, use `Endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details.<br />_default: null_ | `String` |
 | IdempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs.<br />_default: true_ | `Boolean` |
@@ -879,7 +879,7 @@ Returns a promise. On success, the promise is fulfilled with a [`BatchResult`](#
 | LogLevel | A number controlling the verbosity of the log output of the library. Valid values are: 0 (no logs), 1 (errors only), 2 (errors plus connection and channel state changes), 3 (high-level debug output), and 4 (full debug output). | `Integer` |
 | LoggerSink | The default ILoggerSink outputs messages to the debug console. This property allows the user to pipe the log messages to their own logging infrastructure.<br />_default: IO.Ably.DefaultLoggerSink_ | `ILoggerSink` |
 | UseBinaryProtocol | If set to true, will enable the binary protocol (MessagePack) if it is supported. It's disabled by default on browsers for performance considerations (browsers are optimized for decoding JSON). Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency)<br />_default: false_ | `Boolean` |
-| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
+| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [`TokenRequests`](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request.<br />_default: false_ | `Boolean` |
 | DefaultTokenParams | When a [`TokenParams`](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably `TokenRequests`](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
diff --git a/src/pages/docs/api/rest-sdk/authentication.mdx b/src/pages/docs/api/rest-sdk/authentication.mdx
index c06b3a28e6..c7d14050ff 100644
--- a/src/pages/docs/api/rest-sdk/authentication.mdx
+++ b/src/pages/docs/api/rest-sdk/authentication.mdx
@@ -29,7 +29,7 @@ In the documentation, references to Ably-compatible tokens typically refer eithe
 
 ## Auth object <a id="auth-object" />
 
-The principal use-case for the `Auth` object is to create Ably [`TokenRequest`](#token-request) objects with [`createTokenRequest`](#create-token-request) or obtain [Ably Tokens](#token-details) from Ably with [`requestToken`](#request-token), and then issue them to other "less trusted" clients. Typically, your servers should be the only devices to have a [private API key](/docs/auth#api-key), and this private API key is used to securely sign Ably [`TokenRequest`](#token-request) objects or request [Ably Tokens](#token-details) from Ably. Clients are then issued with these short-lived [Ably Tokens](#token-details) or Ably [`TokenRequest`](#token-request) objects, and the libraries can then use these to authenticate with Ably. If you adopt this model, your private API key is never shared with clients directly.
+The principal use-case for the `Auth` object is to create Ably [`TokenRequest`](#token-request) objects with [`createTokenRequest`](#create-token-request) or obtain [Ably Tokens](#token-details) from Ably with [`requestToken`](#request-token), and then issue them to other "less trusted" clients. Typically, your servers should be the only devices to have a [private API key](/docs/platform/auth#api-key), and this private API key is used to securely sign Ably [`TokenRequest`](#token-request) objects or request [Ably Tokens](#token-details) from Ably. Clients are then issued with these short-lived [Ably Tokens](#token-details) or Ably [`TokenRequest`](#token-request) objects, and the libraries can then use these to authenticate with Ably. If you adopt this model, your private API key is never shared with clients directly.
 
 A subsidiary use-case for the `Auth` object is to preemptively trigger renewal of a token or to acquire a new token with a revised set of capabilities by explicitly calling <If lang="javascript,nodejs,php,python,ruby,objc,swift,go,java">[`authorize`](#authorize)</If><If lang="csharp">[`Authorize`](#authorize)</If>.
 
@@ -339,11 +339,11 @@ fmt.Println(token)
 
 </If>
 
-Creates and signs an Ably [`TokenRequest`](#request-token) based on the specified <If lang="ruby,python">`token_params` and `auth_options`</If><If lang="javascript,nodejs,php,java,objc,swift">`tokenParams` and `authOptions`</If><If lang="go">`TokenParams` and `AuthOptions`</If><If lang="csharp">`tokenParams` and `authOptions`</If>. Note this can only be used when the [API `key`](/docs/auth#api-key) value is available locally, due to it being required to sign the Ably [`TokenRequest`](#request-token). Otherwise, Ably [`TokenRequests`](#request-token) must be obtained from the key owner. Use this to generate Ably [`TokenRequests`](#request-token) in order to implement an [Ably Token](#token-details) request callback for use by other clients.
+Creates and signs an Ably [`TokenRequest`](#request-token) based on the specified <If lang="ruby,python">`token_params` and `auth_options`</If><If lang="javascript,nodejs,php,java,objc,swift">`tokenParams` and `authOptions`</If><If lang="go">`TokenParams` and `AuthOptions`</If><If lang="csharp">`tokenParams` and `authOptions`</If>. Note this can only be used when the [API `key`](/docs/platform/auth#api-key) value is available locally, due to it being required to sign the Ably [`TokenRequest`](#request-token). Otherwise, Ably [`TokenRequests`](#request-token) must be obtained from the key owner. Use this to generate Ably [`TokenRequests`](#request-token) in order to implement an [Ably Token](#token-details) request callback for use by other clients.
 
 Both <If lang="ruby,python">`auth_options` and `token_params`</If><If lang="javascript,nodejs,php,java,objc,swift">`authOptions` and `tokenParams`</If><If lang="go">`AuthOptions` and `TokenParams`</If><If lang="csharp">`authOptions` and `tokenParams`</If> are optional. When omitted or <If lang="javascript,nodejs,php,objc,swift,csharp">`null`</If><If lang="java">`Null`</If><If lang="python">`None`</If><If lang="ruby,go">`nil`</If>, the default Ably-compatible token parameters and authentication options for the client library are used, as specified in the `ClientOptions` when the client library was instantiated, or later updated with an explicit <If lang="javascript,nodejs,php,java,ruby,python,objc,swift">[`authorize`](#authorize)</If><If lang="csharp,go">[`Authorize`](#authorize)</If> request. Values passed in will be used instead of (rather than being merged with) the default values.
 
-To understand why an Ably [`TokenRequest`](#request-token) may be issued to clients in favor of an [Ably Token](#token-details), see [Token Authentication explained](/docs/auth/token).
+To understand why an Ably [`TokenRequest`](#request-token) may be issued to clients in favor of an [Ably Token](#token-details), see [Token Authentication explained](/docs/platform/auth/token).
 
 #### Parameters
 
@@ -582,7 +582,7 @@ Calls the <If lang="javascript,nodejs,php,java,ruby,python,objc,swift">[`request
 
 Both <If lang="ruby,python">`auth_options` and `token_params`</If><If lang="javascript,nodejs,php,java,objc,swift">`authOptions` and `tokenParams`</If><If lang="csharp,go">`authOptions` and `tokenParams`</If> are optional. When omitted or <If lang="javascript,nodejs,php,objc,swift">`null`</If><If lang="java">`Null`</If><If lang="python">`None`</If><If lang="ruby,go">`nil`</If><If lang="csharp">`null`</If>, the default token parameters and authentication options for the client library are used, as specified in the `ClientOptions` when the client library was instantiated, or later updated with an explicit <If lang="javascript,nodejs,php,java,ruby,python,objc,swift">[`authorize`](#authorize)</If><If lang="csharp,go">[`Authorize`](#authorize)</If> request. Values passed in will be used instead of (rather than being merged with) the default values.
 
-To understand why an Ably [`TokenRequest`](#request-token) may be issued to clients in favor of an [Ably Token](#token-details), see [Token Authentication explained](/docs/auth/token).
+To understand why an Ably [`TokenRequest`](#request-token) may be issued to clients in favor of an [Ably Token](#token-details), see [Token Authentication explained](/docs/platform/auth/token).
 
 #### Parameters
 
@@ -800,7 +800,7 @@ fmt.Println(token)
 
 Calls the [`revokeTokens` REST API endpoint](/docs/api/rest-api#revoke-tokens) to revoke tokens specified by the provided array of [`TokenRevocationTargetSpecifier`](#token-revocation-target-specifier).
 
-Only tokens issued by an API key that had revocable tokens enabled before the token was issued can be revoked. See the [token revocation docs](/docs/auth/revocation) for more information.
+Only tokens issued by an API key that had revocable tokens enabled before the token was issued can be revoked. See the [token revocation docs](/docs/platform/auth/revocation) for more information.
 
 #### Parameters
 
@@ -854,42 +854,42 @@ try {
 ### <If lang="javascript,nodejs,csharp,objc,php,python,swift,go">AuthOptions Object</If><If lang="ruby">AuthOptions Hash</If><If lang="java">io.ably.lib.rest.Auth.AuthOptions</If> <a id="auth-options" />
 
 <If lang="javascript,nodejs">
-`AuthOptions` is a plain JavaScript object and is used when making [authentication](/docs/auth) requests. If passed in, an `authOptions` object will be used instead of (as opposed to supplementing or being merged with) the default values given when the library was instantiated. The following attributes are supported:
+`AuthOptions` is a plain JavaScript object and is used when making [authentication](/docs/platform/auth) requests. If passed in, an `authOptions` object will be used instead of (as opposed to supplementing or being merged with) the default values given when the library was instantiated. The following attributes are supported:
 </If>
 
 <If lang="ruby">
-`AuthOptions` is a Hash object and is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following key symbol values can be added to the Hash:
+`AuthOptions` is a Hash object and is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following key symbol values can be added to the Hash:
 </If>
 
 <If lang="python">
-`AuthOptions` is a Dict and is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following key symbol values can be added to the Dict:
+`AuthOptions` is a Dict and is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following key symbol values can be added to the Dict:
 </If>
 
 <If lang="php">
-`AuthOptions` is an Associative Array and is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following named keys and values can be added to the Associative Array:
+`AuthOptions` is an Associative Array and is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following named keys and values can be added to the Associative Array:
 </If>
 
 <If lang="java,go">
-`AuthOptions` is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated.
+`AuthOptions` is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated.
 </If>
 
 <If lang="swift,objc">
-`ARTAuthOptions` is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated.
+`ARTAuthOptions` is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated.
 </If>
 
 #### <If lang="javascript,nodejs,csharp,objc,php,swift,go">Properties</If><If lang="java">Members</If><If lang="ruby,python">Attributes</If>
 
 | Name | Description | Type |
 |------|-------------|------|
-| <If lang="javascript,nodejs,java,objc,php,swift">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If> | A <If lang="javascript,nodejs,java,objc,php,swift">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="python">callable (eg a lambda)</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If><If lang="csharp,go">function</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,java,objc,php,swift">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If><If lang="csharp">`Func<TokenParams, Task<object>>`</If><If lang="go">`Callable`</If><If lang="python">`Callable`</If> |
+| <If lang="javascript,nodejs,java,objc,php,swift">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If> | A <If lang="javascript,nodejs,java,objc,php,swift">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="python">callable (eg a lambda)</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If><If lang="csharp,go">function</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,java,objc,php,swift">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If><If lang="csharp">`Func<TokenParams, Task<object>>`</If><If lang="go">`Callable`</If><If lang="python">`Callable`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authUrl</If><If lang="csharp,go">AuthUrl</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | <If lang="javascript,nodejs,java,php,ruby,python,go">`String`</If><If lang="csharp">`Uri`</If><If lang="swift,objc">`NSURL`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authMethod</If><If lang="csharp,go">AuthMethod</If><If lang="python">auth_method</If><If lang="ruby">:auth_method</If> | _<If lang="javascript,nodejs,csharp,java,objc,php,swift,go,python">`GET`</If><If lang="ruby">`:get`</If>_ The HTTP verb to use for the request, either <If lang="javascript,nodejs,csharp,java,objc,php,swift,go,python">`GET`</If><If lang="ruby">`:get`</If> or <If lang="javascript,nodejs,csharp,java,objc,php,swift,go,python">`POST`</If><If lang="ruby">`:post`</If> | <If lang="javascript,nodejs,java,objc,php,swift,go,python">`String`</If><If lang="ruby">`Symbol`</If><If lang="csharp">`HttpMethod`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authHeaders</If><If lang="csharp,go">AuthHeaders</If><If lang="python">auth_headers</If><If lang="ruby">:auth_headers</If> | A set of key value pair headers to be added to any request made to the <If lang="javascript,nodejs,java,objc,php,ruby,python,swift">authUrl</If><If lang="csharp">AuthUrl</If><If lang="go">AuthUrl</If>. Useful when an application requires these to be added to validate the request or implement the response. <If lang="javascript">If the `authHeaders` object contains an `authorization` key, then `withCredentials` will be set on the xhr request.</If> | <If lang="javascript,nodejs,objc,swift,go,csharp">`Object`</If><If lang="python">`Dict`</If><If lang="ruby">`Hash`</If><If lang="php">`Associative Array`</If><If lang="java">`Param []`</If><If lang="csharp">`Dictionary<string, string>`</If> |
 | <If lang="javascript,nodejs,java,objc,php,swift">authParams</If><If lang="csharp,go">AuthParams</If><If lang="ruby">:auth_params</If><If lang="python">auth_params</If> | A set of key value pair params to be added to any request made to the <If lang="javascript,nodejs,java,objc,php,ruby,python,swift">authUrl</If><If lang="csharp,go">AuthUrl</If>. When the <If lang="javascript,nodejs,java,objc,php,ruby,python,swift">authMethod</If><If lang="csharp,go">AuthMethod</If> is `GET`, query params are added to the URL, whereas when <If lang="javascript,nodejs,java,objc,php,ruby,python,swift">authMethod</If><If lang="csharp,go">AuthMethod</If> is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | <If lang="javascript,nodejs,go">`Object`</If><If lang="ruby">`Hash`</If><If lang="php">`Associative Array`</If><If lang="java">`Param[]`</If><If lang="csharp">`Dictionary<string, string>`</If><If lang="objc">`NSArray<NSURLQueryItem *>`</If><If lang="swift">`[NSURLQueryItem]/Array<NSURLQueryItem>`</If><If lang="python">`Object`</If> |
-| <If lang="javascript,nodejs,java,objc,php,swift">tokenDetails</If><If lang="csharp,go">TokenDetails</If><If lang="python">token_details</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,swift">authUrl</If><If lang="csharp,go">AuthUrl</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> or <If lang="javascript,nodejs,java,objc,php,swift">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
-| <If lang="javascript,nodejs,java,objc,php,swift">key</If><If lang="csharp,go">Key</If><If lang="ruby">:key</If><If lang="python">key</If> | Optionally the [API key](/docs/auth#api-key) to use can be specified as a full key string; if not, the API key passed into [`ClientOptions`](#client-options) when instancing the Realtime or REST library is used | `String` |
-| <If lang="javascript,nodejs,java,objc,php,swift">queryTime</If><If lang="csharp,go">QueryTime</If><If lang="ruby">:query_time</If><If lang="python">query_time</If> | _false_ If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/auth/token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. | `Boolean` |
-| <If lang="javascript,nodejs,java,objc,php,swift">token</If><If lang="csharp,go">Token</If><If lang="ruby">:token</If><If lang="python">token</If> | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,java,objc,php,swift">token</If><If lang="csharp,go">Token</If><If lang="python">token</If><If lang="ruby">token</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,swift">authUrl</If><If lang="csharp,go">AuthUrl</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> or <If lang="javascript,nodejs,java,objc,php,swift">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If>. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| <If lang="javascript,nodejs,java,objc,php,swift">tokenDetails</If><If lang="csharp,go">TokenDetails</If><If lang="python">token_details</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,swift">authUrl</If><If lang="csharp,go">AuthUrl</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> or <If lang="javascript,nodejs,java,objc,php,swift">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
+| <If lang="javascript,nodejs,java,objc,php,swift">key</If><If lang="csharp,go">Key</If><If lang="ruby">:key</If><If lang="python">key</If> | Optionally the [API key](/docs/platform/auth#api-key) to use can be specified as a full key string; if not, the API key passed into [`ClientOptions`](#client-options) when instancing the Realtime or REST library is used | `String` |
+| <If lang="javascript,nodejs,java,objc,php,swift">queryTime</If><If lang="csharp,go">QueryTime</If><If lang="ruby">:query_time</If><If lang="python">query_time</If> | _false_ If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/platform/auth/token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. | `Boolean` |
+| <If lang="javascript,nodejs,java,objc,php,swift">token</If><If lang="csharp,go">Token</If><If lang="ruby">:token</If><If lang="python">token</If> | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,java,objc,php,swift">token</If><If lang="csharp,go">Token</If><If lang="python">token</If><If lang="ruby">token</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,java,objc,php,swift">authUrl</If><If lang="csharp,go">AuthUrl</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> or <If lang="javascript,nodejs,java,objc,php,swift">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If>. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
 
 ### <If lang="javascript,nodejs,csharp,php,python,go">TokenDetails Object</If><If lang="objc,swift">ARTTokenDetails</If><If lang="java">io.ably.lib.types.TokenDetails</If><If lang="ruby">Ably::Models::TokenDetails</If> <a id="token-details" />
 
@@ -902,8 +902,8 @@ try {
 | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">token</If><If lang="csharp,go">Token</If> | The [Ably Token](/docs/api/realtime-sdk/authentication#token-details) itself. A typical [Ably Token](/docs/api/realtime-sdk/authentication#token-details) string may appear like `{{TOKEN}}` | `String` |
 | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">expires</If><If lang="csharp,go">Expires</If> | <If lang="javascript,nodejs,csharp,java,php,python,go">The time (in milliseconds since the epoch)</If><If lang="ruby,objc,swift">The time</If> at which this token expires | <If lang="javascript,nodejs,php,python,ruby,go">`Integer`</If><If lang="java">`Long Integer`</If><If lang="csharp">`DateTimeOffset`</If><If lang="ruby">`Time`</If><If lang="objc,swift">`NSDate`</If> |
 | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">issued</If><If lang="csharp,go">Issued</If> | <If lang="javascript,nodejs,csharp,java,php,python,go">The time (in milliseconds since the epoch)</If><If lang="ruby,objc,swift">The time</If> at which this token was issued | <If lang="javascript,nodejs,php,python,ruby,go">`Integer`</If><If lang="java">`Long Integer`</If><If lang="csharp">`DateTimeOffset`</If><If lang="ruby">`Time`</If><If lang="objc,swift">`NSDate`</If> |
-| <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">capability</If><If lang="csharp,go">Capability</If> | The capability associated with this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The capability is a a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/auth/capabilities) | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift,go">`String`</If><If lang="csharp">`Capability`</If> |
-| <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> | The client ID, if any, bound to this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If a client ID is included, then the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) authenticates its bearer as that client ID, and the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) may only be used to perform operations on behalf of that client ID. The client is then considered to be an [identified client](/docs/auth/identified-clients) | `String` |
+| <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">capability</If><If lang="csharp,go">Capability</If> | The capability associated with this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The capability is a a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/platform/auth/capabilities) | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift,go">`String`</If><If lang="csharp">`Capability`</If> |
+| <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> | The client ID, if any, bound to this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If a client ID is included, then the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) authenticates its bearer as that client ID, and the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) may only be used to perform operations on behalf of that client ID. The client is then considered to be an [identified client](/docs/platform/auth/identified-clients) | `String` |
 
 <If lang="ruby">
 ### Methods
@@ -959,35 +959,35 @@ A [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object
 ### <If lang="javascript,nodejs,csharp,php,python,go">TokenParams Object</If><If lang="objc,swift">ARTTokenParams</If><If lang="ruby">TokenParams Hash</If><If lang="java">io.ably.lib.rest.Auth.TokenParams</If> <a id="token-params" />
 
 <If lang="javascript,nodejs">
-`TokenParams` is a plain JavaScript object and is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following attributes can be defined on the object:
+`TokenParams` is a plain JavaScript object and is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following attributes can be defined on the object:
 </If>
 
 <If lang="ruby">
-`TokenParams` is a Hash object and is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following key symbol values can be added to the Hash:
+`TokenParams` is a Hash object and is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following key symbol values can be added to the Hash:
 </If>
 
 <If lang="python">
-`TokenParams` is a Dict and is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following keys-value pairs can be added to the Dict:
+`TokenParams` is a Dict and is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following keys-value pairs can be added to the Dict:
 </If>
 
 <If lang="php">
-`TokenParams` is an Associative Array and is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following named keys and values can be added to the Associative Array:
+`TokenParams` is an Associative Array and is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following named keys and values can be added to the Associative Array:
 </If>
 
 <If lang="java,csharp,go">
-`TokenParams` is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
+`TokenParams` is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
 </If>
 
 <If lang="objc,swift">
-`ARTTokenParams` is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
+`ARTTokenParams` is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
 </If>
 
 #### <If lang="javascript,nodejs,csharp,objc,php,swift,go">Properties</If><If lang="java">Members</If><If lang="ruby,python">Attributes</If>
 
 | Name | Description | Type |
 |------|-------------|------|
-| <If lang="javascript,nodejs,java,objc,php,python,swift">capability</If><If lang="csharp,go">Capability</If><If lang="ruby">:capability</If> | JSON stringified capability of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) request is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. [Find our more about how to use capabilities to manage access privileges for clients](/docs/auth/capabilities). | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift,go">`String`</If><If lang="csharp">`Capability`</If> |
-| <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="csharp,go">ClientId</If><If lang="python">client_id</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> specified here conflicts with the <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
+| <If lang="javascript,nodejs,java,objc,php,python,swift">capability</If><If lang="csharp,go">Capability</If><If lang="ruby">:capability</If> | JSON stringified capability of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) request is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. [Find our more about how to use capabilities to manage access privileges for clients](/docs/platform/auth/capabilities). | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift,go">`String`</If><If lang="csharp">`Capability`</If> |
+| <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="csharp,go">ClientId</If><If lang="python">client_id</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> specified here conflicts with the <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
 | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">nonce</If><If lang="csharp,go">Nonce</If><If lang="ruby">:nonce</If> | An optional opaque nonce string of at least 16 characters to ensure uniqueness of this request. Any subsequent request using the same nonce will be rejected. | `String` |
 | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">timestamp</If><If lang="csharp,go">Timestamp</If><If lang="ruby">:timestamp</If> | <If lang="javascript,nodejs,java,objc,php,python,go">The timestamp (in milliseconds since the epoch)</If><If lang="ruby,objc,swift,csharp">The timestamp</If> of this request. `timestamp`, in conjunction with the `nonce`, is used to prevent requests for [Ably Token](/docs/api/realtime-sdk/authentication#token-details) from being replayed. | <If lang="javascript,nodejs,php,python,go">`Integer`</If><If lang="java">`Long Integer`</If><If lang="ruby">`Time`</If><If lang="objc,swift">`NSDate`</If><If lang="csharp">`DateTimeOffset`</If> |
 | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">ttl</If><If lang="csharp,go">Ttl</If><If lang="ruby">:ttl</If> | _1 hour_ Requested time to live for the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) being created <If lang="javascript,nodejs,java,objc,php,python,go">in milliseconds</If><If lang="ruby">in seconds</If><If lang="objc,swift">as a `NSTimeInterval`</If><If lang="csharp,go">as a `TimeSpan`.</If> When omitted, the Ably REST API default of 60 minutes is applied by Ably | <If lang="javascript,nodejs,php,python,go">`Integer` (milliseconds)</If><If lang="ruby">`Integer` (seconds)</If><If lang="objc,swift">`NSTimeInterval`</If><If lang="java">`Long Integer`</If><If lang="csharp">`TimeSpan`</If> |
@@ -1003,7 +1003,7 @@ A [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object
 | <If lang="javascript,nodejs,java,objc,php,swift">keyName</If><If lang="ruby,python">key_name</If><If lang="csharp,go">KeyName</If> | The key name of the key against which this request is made. The key name is public, whereas the key secret is private | `String` |
 | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">ttl</If><If lang="csharp">Ttl</If> | Requested time to live for the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) <If lang="javascript,nodejs,java,objc,php,python,go">in milliseconds</If><If lang="ruby">in seconds</If><If lang="csharp,go">as a `TimeSpan`</If>. If the Ably `TokenRequest` is successful, the TTL of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be less than or equal to this value depending on application settings and the attributes of the issuing key. | <If lang="javascript,nodejs,php,python,ruby,go">`Integer`</If><If lang="csharp">`TimeSpan`</If><If lang="swift,objc">`NSTimeInterval`</If><If lang="java">`Integer`</If> |
 | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">timestamp</If><If lang="csharp,go">Timestamp</If> | The timestamp of this request<If lang="javascript,nodejs,java,objc,php,python,go"> in milliseconds</If> | <If lang="javascript,nodejs,php,python,go">`Integer`</If><If lang="java">`Long Integer`</If><If lang="ruby">`Time`</If><If lang="csharp">`DateTimeOffset`</If><If lang="swift,objc">`NSDate`</If> |
-| <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">capability</If><If lang="csharp,go">Capability</If> | Capability of the requested [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the Ably `TokenRequest` is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. The capability is a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/auth) | `String` |
+| <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">capability</If><If lang="csharp,go">Capability</If> | Capability of the requested [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the Ably `TokenRequest` is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. The capability is a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/platform/auth) | `String` |
 | <If lang="javascript,nodejs,java,objc,php,swift">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> | The client ID to associate with the requested [Ably Token](/docs/api/realtime-sdk/authentication#token-details). When provided, the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) may only be used to perform operations on behalf of that client ID | `String` |
 | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">nonce</If><If lang="csharp,go">Nonce</If> | An opaque nonce string of at least 16 characters | `String` |
 | <If lang="javascript,nodejs,java,objc,php,python,ruby,swift">mac</If><If lang="csharp,go">Mac</If> | The Message Authentication Code for this request | `String` |
@@ -1047,7 +1047,7 @@ An Ably JWT is not strictly an Ably construct, rather it is a [JWT](https://jwt.
 
 Arbitrary additional claims and headers are supported (apart from those prefixed with `x-ably-` which are reserved for future use).
 
-The Ably JWT must be signed with the secret part of your [Ably API key](/docs/auth#api-key) using the signature algorithm HS256 (HMAC using the SHA-256 hash algorithm). View the [JSON Web Algorithms (JWA) specification](https://tools.ietf.org/html/rfc7518) for further information.
+The Ably JWT must be signed with the secret part of your [Ably API key](/docs/platform/auth#api-key) using the signature algorithm HS256 (HMAC using the SHA-256 hash algorithm). View the [JSON Web Algorithms (JWA) specification](https://tools.ietf.org/html/rfc7518) for further information.
 
 We recommend you use one of the many [JWT libraries available for simplicity](https://jwt.io/) when creating your JWTs.
 
diff --git a/src/pages/docs/api/rest-sdk/channels.mdx b/src/pages/docs/api/rest-sdk/channels.mdx
index c9863086d1..ad5eae852b 100644
--- a/src/pages/docs/api/rest-sdk/channels.mdx
+++ b/src/pages/docs/api/rest-sdk/channels.mdx
@@ -481,7 +481,7 @@ On failure to retrieve message history, the `error` contains an [`ErrorInfo`](#e
 `Message get_message(serial_or_message)`
 </If>
 
-Retrieves the latest version of a specific message by its serial identifier. Requires the **history** [capability](/docs/auth/capabilities).
+Retrieves the latest version of a specific message by its serial identifier. Requires the **history** [capability](/docs/platform/auth/capabilities).
 
 See [updating and deleting messages: retrieving the latest version](/docs/messages/updates-deletes#get) for more information.
 
@@ -533,7 +533,7 @@ On failure, raises an [`AblyException`](/docs/api/realtime-sdk/types#ably-except
 `UpdateDeleteResult update_message(message, operation=None, params=dict())`
 </If>
 
-Publishes an update to an existing message with shallow mixin semantics. Non-null `name`, `data`, and `extras` fields in the provided message will replace the corresponding fields in the existing message, while null fields will be left unchanged. Requires the **message-update-own** or **message-update-any** [capability](/docs/auth/capabilities).
+Publishes an update to an existing message with shallow mixin semantics. Non-null `name`, `data`, and `extras` fields in the provided message will replace the corresponding fields in the existing message, while null fields will be left unchanged. Requires the **message-update-own** or **message-update-any** [capability](/docs/platform/auth/capabilities).
 
 See [updating and deleting messages: updates](/docs/messages/updates-deletes#update) for more information.
 
@@ -571,7 +571,7 @@ Returns an [`UpdateDeleteResult`](/docs/api/realtime-sdk/types#update-delete-res
 `UpdateDeleteResult delete_message(message, operation=None, params=dict())`
 </If>
 
-Marks a message as deleted by publishing an update with an action of `MESSAGE_DELETE`. This does not remove the message from the server, and the full message history remains accessible. Uses shallow mixin semantics: non-null `name`, `data`, and `extras` fields in the provided message will replace the corresponding fields in the existing message, while null fields will be left unchanged. Requires the **message-delete-own** or **message-delete-any** [capability](/docs/auth/capabilities).
+Marks a message as deleted by publishing an update with an action of `MESSAGE_DELETE`. This does not remove the message from the server, and the full message history remains accessible. Uses shallow mixin semantics: non-null `name`, `data`, and `extras` fields in the provided message will replace the corresponding fields in the existing message, while null fields will be left unchanged. Requires the **message-delete-own** or **message-delete-any** [capability](/docs/platform/auth/capabilities).
 
 See [updating and deleting messages: deletes](/docs/messages/updates-deletes#delete) for more information.
 
@@ -609,7 +609,7 @@ Returns an [`UpdateDeleteResult`](/docs/api/realtime-sdk/types#update-delete-res
 `UpdateDeleteResult append_message(message, operation=None, params=dict())`
 </If>
 
-Appends data to an existing message. The supplied `data` field is appended to the previous message's data, while all other fields (`name`, `extras`) replace the previous values if provided. Requires the **message-update-own** or **message-update-any** [capability](/docs/auth/capabilities).
+Appends data to an existing message. The supplied `data` field is appended to the previous message's data, while all other fields (`name`, `extras`) replace the previous values if provided. Requires the **message-update-own** or **message-update-any** [capability](/docs/platform/auth/capabilities).
 
 For publishing a high rate of appends, you typically want to use a realtime client, not a REST client, in order to have message order preservation. See [append ordering](/docs/messages/updates-deletes#append-ordering).
 
@@ -649,7 +649,7 @@ Returns an [`UpdateDeleteResult`](/docs/api/realtime-sdk/types#update-delete-res
 `PaginatedResult get_message_versions(serial_or_message, **params)`
 </If>
 
-Retrieves all historical versions of a specific message, ordered by version. This includes the original message and all subsequent updates or delete operations. Requires the **history** [capability](/docs/auth/capabilities).
+Retrieves all historical versions of a specific message, ordered by version. This includes the original message and all subsequent updates or delete operations. Requires the **history** [capability](/docs/platform/auth/capabilities).
 
 See [updating and deleting messages: versions](/docs/messages/updates-deletes#versions) for more information.
 
diff --git a/src/pages/docs/api/rest-sdk/push-admin.mdx b/src/pages/docs/api/rest-sdk/push-admin.mdx
index 097fb57e21..116dfa392f 100644
--- a/src/pages/docs/api/rest-sdk/push-admin.mdx
+++ b/src/pages/docs/api/rest-sdk/push-admin.mdx
@@ -29,7 +29,7 @@ The returned [`DeviceRegistrations`](#device-registrations-object) object provid
 
 #### <If lang="javascript,nodejs,java,android,php,swift,objc">channelSubscriptions</If><If lang="ruby">channel_subscriptions</If> <a id="channel-subscriptions" />
 
-The returned [`PushChannelSubscriptions`](#push-channel-subscriptions) object provides functionality for subscribing, listing and unsubscribing individual devices or groups of [identified devices](/docs/auth/identified-clients) to push notifications published on channels.
+The returned [`PushChannelSubscriptions`](#push-channel-subscriptions) object provides functionality for subscribing, listing and unsubscribing individual devices or groups of [identified devices](/docs/platform/auth/identified-clients) to push notifications published on channels.
 
 ### Methods <a id="methods" />
 
@@ -65,7 +65,7 @@ The returned [`PushChannelSubscriptions`](#push-channel-subscriptions) object pr
 
 </If>
 
-Publishes a push notification directly to a device or group of devices sharing a [client identifier](/docs/auth/identified-clients). See the [push notification direct publishing documentation](/docs/push/publish#direct-publishing) for more information.
+Publishes a push notification directly to a device or group of devices sharing a [client identifier](/docs/platform/auth/identified-clients). See the [push notification direct publishing documentation](/docs/push/publish#direct-publishing) for more information.
 
 ##### Parameters
 
@@ -692,7 +692,7 @@ This object is accessible through <If lang="javascript,nodejs,java,android,php,s
 
 </If>
 
-Retrieve all push channel subscriptions that match the provided params filter as a paginated list of [`PushChannelSubscription`](#push-channel-subscription) objects. Each [`PushChannelSubscription`](#push-channel-subscription) represents a device or set of devices sharing the same [client identifier](/docs/auth/identified-clients) registered to a channel to receive push notifications.
+Retrieve all push channel subscriptions that match the provided params filter as a paginated list of [`PushChannelSubscription`](#push-channel-subscription) objects. Each [`PushChannelSubscription`](#push-channel-subscription) represents a device or set of devices sharing the same [client identifier](/docs/platform/auth/identified-clients) registered to a channel to receive push notifications.
 
 ##### Parameters
 
@@ -876,7 +876,7 @@ Failure to retrieve the channels will trigger the `errback` callbacks of the [`D
 
 </If>
 
-Subscribe a device or group of devices sharing a [client identifier](/docs/auth/identified-clients) for push notifications published on a channel.
+Subscribe a device or group of devices sharing a [client identifier](/docs/platform/auth/identified-clients) for push notifications published on a channel.
 
 ##### Parameters
 
@@ -934,7 +934,7 @@ On failure to create or update the channel subscription, `err` contains an [`Err
 
 </If>
 
-Unsubscribe a device or group of devices sharing a [client identifier](/docs/auth/identified-clients) from push notifications on a channel. Requires `push-admin` permission or, in the case of a subscription associated with a given `deviceId`, `push-subscribe` permission together with device authentication matching that `deviceId`.
+Unsubscribe a device or group of devices sharing a [client identifier](/docs/platform/auth/identified-clients) from push notifications on a channel. Requires `push-admin` permission or, in the case of a subscription associated with a given `deviceId`, `push-subscribe` permission together with device authentication matching that `deviceId`.
 
 ##### Parameters
 
@@ -1037,7 +1037,7 @@ A `DeviceDetails` is a type encapsulating attributes of a device registered for
 | Property | Description | Type |
 |----------|-------------|------|
 | id | unique identifier for the device generated by the device itself | String |
-| <If lang="javascript,nodejs,java,android,php,swift,objc">clientId</If><If lang="ruby">client_id</If> | optional trusted [client identifier](/docs/auth/identified-clients) for the device | String |
+| <If lang="javascript,nodejs,java,android,php,swift,objc">clientId</If><If lang="ruby">client_id</If> | optional trusted [client identifier](/docs/platform/auth/identified-clients) for the device | String |
 | <If lang="javascript,nodejs,java,android,php,swift,objc">formFactor</If><If lang="ruby">form_factor</If> | form factor of the push device. Must be one of `phone`, `tablet`, `desktop`, `tv`, `watch`, `car` <If lang="javascript,nodejs,java,android,php,ruby,swift,objc">or `embedded`</If><If lang="javascript,nodejs">or `other`</If> | String |
 | <If lang="javascript,nodejs,java,android,php,ruby,swift,objc">metadata</If> | optional metadata object for this device. The metadata for a device may only be set by clients with `push-admin` privileges | <If lang="javascript,nodejs,java,android,swift,objc">Object</If><If lang="php">Array</If><If lang="ruby">Hash</If> |
 | <If lang="javascript,nodejs,java,android,php,ruby,swift,objc">platform</If> | platform of the push device. Must be one of `ios` <If lang="javascript,nodejs,java,android,php,ruby,swift,objc">or `android`</If><If lang="javascript,nodejs">or `browser`</If> | String |
@@ -1210,7 +1210,7 @@ Failure to retrieve the message history will raise an [`AblyException`](/docs/ap
 
 ### <If lang="javascript,nodejs,php">PushChannelSubscription</If><If lang="ruby">Ably::Models::PushChannelSubscription</If><If lang="java,android">ChannelSubscription</If><If lang="swift,objc">ARTPushChannelSubscription</If> <a id="push-channel-subscription" />
 
-An `PushChannelSubscription` is a type encapsulating the subscription of a device or group of devices sharing a [client identifier](/docs/auth/identified-clients) to a channel in order to receive push notifications.
+An `PushChannelSubscription` is a type encapsulating the subscription of a device or group of devices sharing a [client identifier](/docs/platform/auth/identified-clients) to a channel in order to receive push notifications.
 
 #### <If lang="javascript,nodejs,java,android,php,swift,objc">Properties</If><If lang="ruby">Attributes</If>
 
@@ -1218,7 +1218,7 @@ An `PushChannelSubscription` is a type encapsulating the subscription of a devic
 |----------|-------------|------|
 | channel | the channel that this push notification subscription is associated with | String |
 | <If lang="javascript,nodejs,java,android,php,swift,objc">deviceId</If><If lang="ruby">device_id</If> | the device with this identifier is linked to this channel subscription. When present, <If lang="javascript,nodejs,java,android,php,swift,objc">`clientId`</If><If lang="ruby">`client_id`</If> is never present | String |
-| <If lang="javascript,nodejs,java,android,php,swift,objc">clientId</If><If lang="ruby">client_id</If> | devices with this [client identifier](/docs/auth/identified-clients) are included in this channel subscription. When present, <If lang="javascript,nodejs,java,android,php,swift,objc">`deviceId`</If><If lang="ruby">`device_id`</If> is never present | String |
+| <If lang="javascript,nodejs,java,android,php,swift,objc">clientId</If><If lang="ruby">client_id</If> | devices with this [client identifier](/docs/platform/auth/identified-clients) are included in this channel subscription. When present, <If lang="javascript,nodejs,java,android,php,swift,objc">`deviceId`</If><If lang="ruby">`device_id`</If> is never present | String |
 
 <If lang="java,android,php,ruby,swift,objc">
 
@@ -1265,14 +1265,14 @@ A [`PushChannelSubscription`](/docs/api/realtime-sdk/types#push-channel-subscrip
 
 </If>
 
-A static factory method to create a `PushChannelSubscription` object for a channel and group of devices sharing a [client identifier](/docs/auth/identified-clients).
+A static factory method to create a `PushChannelSubscription` object for a channel and group of devices sharing a [client identifier](/docs/platform/auth/identified-clients).
 
 ##### Parameters
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
 | channel | channel name linked to this push channel subscription | String |
-| <If lang="javascript,nodejs,java,android,php,swift,objc">clientId</If><If lang="ruby">client_id</If> | devices with this [client identifier](/docs/auth/identified-clients) are included in the new push channel subscription | String |
+| <If lang="javascript,nodejs,java,android,php,swift,objc">clientId</If><If lang="ruby">client_id</If> | devices with this [client identifier](/docs/platform/auth/identified-clients) are included in the new push channel subscription | String |
 
 ##### Returns
 
diff --git a/src/pages/docs/api/rest-sdk/types.mdx b/src/pages/docs/api/rest-sdk/types.mdx
index 81f15018c3..742bb0cc7c 100644
--- a/src/pages/docs/api/rest-sdk/types.mdx
+++ b/src/pages/docs/api/rest-sdk/types.mdx
@@ -1353,8 +1353,8 @@ Please note that `key` and `value` attributes are always strings. If an `Integer
 | <If lang="javascript,nodejs,flutter,java,objc,swift,php,ruby,python">token</If><If lang="csharp,go">Token</If> | The [Ably Token](/docs/api/realtime-sdk/authentication#token-details) itself. A typical [Ably Token](/docs/api/realtime-sdk/authentication#token-details) string may appear like `{{TOKEN}}` | `String` |
 | <If lang="javascript,nodejs,flutter,java,objc,swift,php,ruby,python">expires</If><If lang="csharp,go">Expires</If> | <If lang="javascript,nodejs,flutter,java,php,python">The time (in milliseconds since the epoch)</If><If lang="ruby,objc,swift">The time</If> at which this token expires | <If lang="javascript,nodejs,flutter,php,python">`Integer`</If><If lang="java">`Long Integer`</If><If lang="csharp">`DateTimeOffset`</If><If lang="ruby">`Time`</If><If lang="objc,swift">`NSDate`</If> |
 | <If lang="javascript,nodejs,flutter,java,objc,swift,php,ruby,python">issued</If><If lang="csharp,go">Issued</If> | <If lang="javascript,nodejs,flutter,java,php,python">The time (in milliseconds since the epoch)</If><If lang="ruby,objc,swift">The time</If> at which this token was issued | <If lang="javascript,nodejs,flutter,php,python">`Integer`</If><If lang="java">`Long Integer`</If><If lang="csharp">`DateTimeOffset`</If><If lang="ruby">`Time`</If><If lang="objc,swift">`NSDate`</If> |
-| <If lang="javascript,nodejs,flutter,java,objc,swift,php,ruby,python">capability</If><If lang="csharp,go">Capability</If> | The capability associated with this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The capability is a a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/auth/capabilities) | <If lang="javascript,nodejs,flutter,java,objc,swift,php,ruby,python,go">`String`</If><If lang="csharp">`Capability`</If> |
-| <If lang="javascript,nodejs,flutter,java,objc,swift,php">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> | The client ID, if any, bound to this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If a client ID is included, then the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) authenticates its bearer as that client ID, and the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) may only be used to perform operations on behalf of that client ID. The client is then considered to be an [identified client](/docs/auth/identified-clients) | `String` |
+| <If lang="javascript,nodejs,flutter,java,objc,swift,php,ruby,python">capability</If><If lang="csharp,go">Capability</If> | The capability associated with this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The capability is a a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/platform/auth/capabilities) | <If lang="javascript,nodejs,flutter,java,objc,swift,php,ruby,python,go">`String`</If><If lang="csharp">`Capability`</If> |
+| <If lang="javascript,nodejs,flutter,java,objc,swift,php">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> | The client ID, if any, bound to this [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If a client ID is included, then the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) authenticates its bearer as that client ID, and the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) may only be used to perform operations on behalf of that client ID. The client is then considered to be an [identified client](/docs/platform/auth/identified-clients) | `String` |
 
 <If lang="ruby">
 
@@ -1438,7 +1438,7 @@ A [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object
 | <If lang="javascript,nodejs,flutter,objc,swift,php,java">keyName</If><If lang="ruby,python">key_name</If><If lang="csharp,go">KeyName</If> | The key name of the key against which this request is made. The key name is public, whereas the key secret is private | `String` |
 | <If lang="javascript,nodejs,flutter,objc,swift,php,java,ruby,python,go">ttl</If><If lang="csharp">Ttl</If> | Requested time to live for the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) <If lang="javascript,nodejs,flutter,objc,swift,php,java,python">in milliseconds</If><If lang="ruby">in seconds</If><If lang="csharp,go">as a `TimeSpan`</If>. If the Ably `TokenRequest` is successful, the TTL of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be less than or equal to this value depending on application settings and the attributes of the issuing key. | <If lang="javascript,nodejs,flutter,php,java,python,ruby,go">`Integer`</If><If lang="csharp">`TimeSpan`</If><If lang="swift,objc">`NSTimeInterval`</If> |
 | <If lang="javascript,nodejs,flutter,objc,swift,php,java,ruby,python">timestamp</If><If lang="csharp,go">Timestamp</If> | The timestamp of this request<If lang="javascript,nodejs,flutter,objc,swift,php,java,python"> in milliseconds</If> | <If lang="javascript,nodejs,flutter,php,python,go">`Integer`</If><If lang="java">`Long Integer`</If><If lang="ruby">`Time`</If><If lang="csharp">`DateTimeOffset`</If><If lang="swift,objc">`NSDate`</If> |
-| <If lang="javascript,nodejs,flutter,objc,swift,php,java,ruby,python">capability</If><If lang="csharp,go">Capability</If> | Capability of the requested [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the Ably `TokenRequest` is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. The capability is a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/auth) | `String` |
+| <If lang="javascript,nodejs,flutter,objc,swift,php,java,ruby,python">capability</If><If lang="csharp,go">Capability</If> | Capability of the requested [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the Ably `TokenRequest` is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. The capability is a JSON stringified canonicalized representation of the resource paths and associated operations. [Read more about authentication and capabilities](/docs/platform/auth) | `String` |
 | <If lang="javascript,nodejs,flutter,objc,swift,php,java">clientId</If><If lang="ruby,python">client_id</If><If lang="csharp,go">ClientId</If> | The client ID to associate with the requested [Ably Token](/docs/api/realtime-sdk/authentication#token-details). When provided, the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) may only be used to perform operations on behalf of that client ID | `String` |
 | <If lang="javascript,nodejs,flutter,objc,swift,php,java,ruby,python">nonce</If><If lang="csharp,go">Nonce</If> | An opaque nonce string of at least 16 characters | `String` |
 | <If lang="javascript,nodejs,flutter,objc,swift,php,java,ruby,python">mac</If><If lang="csharp,go">Mac</If> | The Message Authentication Code for this request | `String` |
@@ -1772,27 +1772,27 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 <If lang="javascript,nodejs">
 
-`AuthOptions` is a plain JavaScript object and is used when making [authentication](/docs/auth) requests. If passed in, an `authOptions` object will be used instead of (as opposed to supplementing or being merged with) the default values given when the library was instantiated. The following attributes are supported:
+`AuthOptions` is a plain JavaScript object and is used when making [authentication](/docs/platform/auth) requests. If passed in, an `authOptions` object will be used instead of (as opposed to supplementing or being merged with) the default values given when the library was instantiated. The following attributes are supported:
 
 </If>
 <If lang="ruby">
 
-`AuthOptions` is a Hash object and is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following key symbol values can be added to the Hash:
+`AuthOptions` is a Hash object and is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following key symbol values can be added to the Hash:
 
 </If>
 <If lang="python">
 
-`AuthOptions` is a Dict and is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following key symbol values can be added to the Dict:
+`AuthOptions` is a Dict and is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following key symbol values can be added to the Dict:
 
 </If>
 <If lang="php">
 
-`AuthOptions` is an Associative Array and is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following named keys and values can be added to the Associative Array:
+`AuthOptions` is an Associative Array and is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated. The following named keys and values can be added to the Associative Array:
 
 </If>
 <If lang="java,swift,objc,go">
 
-<If lang="swift,objc">`ART`</If>`AuthOptions` is used when making [authentication](/docs/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated.
+<If lang="swift,objc">`ART`</If>`AuthOptions` is used when making [authentication](/docs/platform/auth) requests. These options will supplement or override the corresponding options given when the library was instantiated.
 
 </If>
 
@@ -1800,15 +1800,15 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| <If lang="javascript,nodejs,flutter,php,java,objc,swift">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If> | A <If lang="javascript,nodejs,flutter,php,objc,swift,csharp,go">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="python">callable (eg a lambda)</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,flutter,php,objc,swift,go">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If><If lang="csharp">`Func<TokenParams, Task<object>>`</If><If lang="python">`Callable`</If> |
+| <If lang="javascript,nodejs,flutter,php,java,objc,swift">authCallback</If><If lang="csharp,go">AuthCallback</If><If lang="python">auth_callback</If><If lang="ruby">:auth_callback</If> | A <If lang="javascript,nodejs,flutter,php,objc,swift,csharp,go">function</If><If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If><If lang="java">`TokenCallback` instance</If><If lang="python">callable (eg a lambda)</If><If lang="ruby">proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter)</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | <If lang="javascript,nodejs,flutter,php,objc,swift,go">`Callable`</If><If lang="java">`TokenCallback`</If><If lang="ruby">`Proc`</If><If lang="csharp">`Func<TokenParams, Task<object>>`</If><If lang="python">`Callable`</If> |
 | <If lang="javascript,nodejs,flutter,php,java,objc,swift">authUrl</If><If lang="csharp,go">AuthUrl</If><If lang="ruby">:auth_url</If><If lang="python">auth_url</If> | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | <If lang="javascript,nodejs,flutter,php,java,ruby,python,go">`String`</If><If lang="csharp">`Uri`</If><If lang="swift,objc">`NSURL`</If> |
 | <If lang="javascript,nodejs,flutter,php,java,objc,swift">authMethod</If><If lang="csharp,go">AuthMethod</If><If lang="python">auth_method</If><If lang="ruby">:auth_method</If> | The HTTP verb to use for the request, either <If lang="javascript,nodejs,flutter,php,java,objc,swift,python,csharp,go">`GET`</If><If lang="ruby">`:get`</If> or <If lang="javascript,nodejs,flutter,php,java,objc,swift,python,csharp,go">`POST`</If><If lang="ruby">`:post`</If>. The default is <If lang="javascript,nodejs,flutter,php,java,objc,swift,python,csharp,go">`GET`</If><If lang="ruby">`:get`</If>. | <If lang="javascript,nodejs,flutter,php,java,objc,swift,python,go">`String`</If><If lang="ruby">`Symbol`</If><If lang="csharp">`HttpMethod`</If> |
 | <If lang="javascript,nodejs,flutter,php,java,objc,swift">authHeaders</If><If lang="csharp,go">AuthHeaders</If><If lang="python">auth_headers</If><If lang="ruby">:auth_headers</If> | A set of key value pair headers to be added to any request made to the <If lang="javascript,nodejs,flutter,php,java,objc,swift,python,ruby,go">`authUrl`</If><If lang="csharp">`AuthUrl`</If>. Useful when an application requires these to be added to validate the request or implement the response. <If lang="javascript">If the `authHeaders` object contains an `authorization` key, then `withCredentials` will be set on the xhr request.</If> | <If lang="javascript,nodejs,objc,swift">`Object`</If><If lang="python">`Dict`</If><If lang="ruby">`Hash`</If><If lang="php">Associative Array</If><If lang="java">`Param []`</If><If lang="csharp">`Dictionary<string, string>`</If><If lang="flutter">`Map<String, String>`</If><If lang="go">`Object`</If> |
 | <If lang="javascript,nodejs,flutter,php,java,objc,swift">authParams</If><If lang="csharp,go">AuthParams</If><If lang="ruby">:auth_params</If><If lang="python">auth_params</If> | A set of key value pair params to be added to any request made to the <If lang="javascript,nodejs,flutter,php,java,objc,swift,python,ruby">`authUrl`</If><If lang="csharp">`AuthUrl`</If>. When the <If lang="javascript,nodejs,flutter,php,java,objc,swift,python,ruby">`authMethod`</If><If lang="csharp,go">`AuthMethod`</If> is `GET`, query params are added to the URL, whereas when <If lang="javascript,nodejs,flutter,php,java,objc,swift,python,ruby">`authMethod`</If><If lang="csharp,go">`AuthMethod`</If> is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | <If lang="javascript,nodejs">`Object`</If><If lang="ruby">`Hash`</If><If lang="php">Associative Array</If><If lang="java">`Param[]`</If><If lang="csharp">`Dictionary<string, string>`</If><If lang="objc">`NSArray<NSURLQueryItem *>`</If><If lang="swift">`[NSURLQueryItem]/Array<NSURLQueryItem>`</If><If lang="flutter">`Map<String, String>`</If><If lang="python">`Object`</If><If lang="go">`Object`</If> |
-| <If lang="javascript,nodejs,flutter,php,java,objc,swift">tokenDetails</If><If lang="csharp,go">TokenDetails</If><If lang="python">token_details</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,flutter,php,java,objc,swift">`authUrl`</If><If lang="csharp,go">`AuthUrl`</If><If lang="ruby">`:auth_url`</If><If lang="python">`auth_url`</If> or <If lang="javascript,nodejs,flutter,php,java,objc,swift">`authCallback`</If><If lang="csharp,go">`AuthCallback`</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
-| <If lang="javascript,nodejs,flutter,php,java,objc,swift">key</If><If lang="csharp,go">Key</If><If lang="ruby">:key</If><If lang="python">key</If> | Optionally the [API key](/docs/auth#api-key) to use can be specified as a full key string; if not, the API key passed into [`ClientOptions`](#client-options) when instancing the Realtime or REST library is used | `String` |
-| <If lang="javascript,nodejs,flutter,php,java,objc,swift">queryTime</If><If lang="csharp,go">QueryTime</If><If lang="ruby">:query_time</If><If lang="python">query_time</If> | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/auth/token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
-| <If lang="javascript,nodejs,flutter,php,java,objc,swift">token</If><If lang="csharp,go">Token</If><If lang="ruby">:token</If><If lang="python">token</If> | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,flutter,php,java,objc,swift,python">`token`</If><If lang="csharp,go">`Token`</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,flutter,php,java,objc,swift">`authUrl`</If><If lang="csharp,go">`AuthUrl`</If><If lang="ruby">`:auth_url`</If><If lang="python">`auth_url`</If> or <If lang="javascript,nodejs,flutter,php,java,objc,swift">`authCallback`</If><If lang="csharp,go">`AuthCallback`</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| <If lang="javascript,nodejs,flutter,php,java,objc,swift">tokenDetails</If><If lang="csharp,go">TokenDetails</If><If lang="python">token_details</If><If lang="ruby">:token_details</If> | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,flutter,php,java,objc,swift">`authUrl`</If><If lang="csharp,go">`AuthUrl`</If><If lang="ruby">`:auth_url`</If><If lang="python">`auth_url`</If> or <If lang="javascript,nodejs,flutter,php,java,objc,swift">`authCallback`</If><If lang="csharp,go">`AuthCallback`</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
+| <If lang="javascript,nodejs,flutter,php,java,objc,swift">key</If><If lang="csharp,go">Key</If><If lang="ruby">:key</If><If lang="python">key</If> | Optionally the [API key](/docs/platform/auth#api-key) to use can be specified as a full key string; if not, the API key passed into [`ClientOptions`](#client-options) when instancing the Realtime or REST library is used | `String` |
+| <If lang="javascript,nodejs,flutter,php,java,objc,swift">queryTime</If><If lang="csharp,go">QueryTime</If><If lang="ruby">:query_time</If><If lang="python">query_time</If> | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/platform/auth/token), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
+| <If lang="javascript,nodejs,flutter,php,java,objc,swift">token</If><If lang="csharp,go">Token</If><If lang="ruby">:token</If><If lang="python">token</If> | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the <If lang="javascript,nodejs,flutter,php,java,objc,swift,python">`token`</If><If lang="csharp,go">`Token`</If> property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as <If lang="javascript,nodejs,flutter,php,java,objc,swift">`authUrl`</If><If lang="csharp,go">`AuthUrl`</If><If lang="ruby">`:auth_url`</If><If lang="python">`auth_url`</If> or <If lang="javascript,nodejs,flutter,php,java,objc,swift">`authCallback`</If><If lang="csharp,go">`AuthCallback`</If><If lang="python">`auth_callback`</If><If lang="ruby">`:auth_callback`</If>. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
 
 
 ### <If lang="javascript,nodejs,flutter,python,go">ClientOptions Object</If><If lang="objc,swift">ARTClientOptions</If><If lang="ruby">ClientOptions Hash</If><If lang="php">ClientOptions Array</If><If lang="java">io.ably.types.ClientOptions</If><If lang="csharp">IO.Ably.ClientOptions</If> <a id="client-options" />
@@ -1845,17 +1845,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A function<If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A function<If lang="javascript,nodejs">function with the form `function(tokenParams, callback(err, tokenOrTokenRequest))`</If> which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `String` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`. The default is `GET`. | `String` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. <If lang="javascript">If the `authHeaders` object contains an `authorization` key, then `withCredentials` will be set on the xhr request.</If> | `Object` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | `Object` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls). The default is true. | `Boolean` |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is null. | `String` |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is null. | `String` |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs. The default is true. | `Boolean` |
@@ -1865,7 +1865,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | logHandler | A function to handle each line of the library's log output. If `logHandler` is not specified, `console.log` is used. | `Callable` |
 | transports | An optional array of transports to use, in descending order of preference. <If lang="javascript">In the browser environment the available transports are: `web_socket`, `xhr_polling`.</If><If lang="nodejs">The transports available in the Node.js client library are: `web_socket`, `xhr_polling`, `comet`.</If> | `String []` |
 | useBinaryProtocol | <If lang="javascript">If set to true, will enable the binary protocol (MessagePack) if it is supported. It's disabled by default on browsers for performance considerations (browsers are optimized for decoding JSON). The default is false.</If><If lang="nodejs">If set to false, will forcibly disable the binary protocol (MessagePack). The binary protocol is used by default unless it is not supported. The default is true.</If> Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency) | `Boolean` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
 | defaultTokenParams | When a [TokenParams](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably TokenRequests](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 
@@ -1874,17 +1874,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A `TokenCallback` instance which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `TokenCallback` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A `TokenCallback` instance which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `TokenCallback` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `String` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`. The default is `GET`. | `String` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. | `Param []` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | `Param[]` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls). The default is true. | `Boolean` |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is Null. | `String` |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is Null. | `String` |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs. The default is true. | `Boolean` |
@@ -1893,7 +1893,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | logLevel | A number controlling the verbosity of the output from 2 (maximum, verbose) to 6 (errors only). A special value of 99 will silence all logging. Note that the `logLevel` is a static variable in the library and will thus not act independently between library instances when multiple library instances exist concurrently. See [the logging section of the java library README](https://github.com/ably/ably-java/#logging) for more details. The default is 5. | `Integer` |
 | logHandler | A `LogHandler` interface can be specified to handle each line of log output. If `logHandler` is not specified, `System.out` is used. Note that the `logHandler` is a static variable in the library and will thus not act independently between library instances when multiple library instances exist concurrently. See [the logging section of the java library README](https://github.com/ably/ably-java/#logging) for more details. The default is `System.out PrintStream`. | `PrintStream` |
 | useBinaryProtocol | If set to false, will forcibly disable the binary protocol (MessagePack). The binary protocol is used by default unless it is not supported. The default is true. Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency) | `Boolean` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
 | defaultTokenParams | When a [TokenParams](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably TokenRequests](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -1901,17 +1901,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| Token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `Token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `Func<TokenParams, Task<object>>` |
+| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| Token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `Token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `Func<TokenParams, Task<object>>` |
 | AuthUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `Uri` |
 | AuthMethod | The HTTP verb to use for the request, either `GET` or `POST`. The default is `GET`. | `HttpMethod` |
 | AuthHeaders | A set of key value pair headers to be added to any request made to the `AuthUrl`. Useful when an application requires these to be added to validate the request or implement the response. | `Dictionary<string, string>` |
 | AuthParams | A set of key value pair params to be added to any request made to the `AuthUrl`. When the `AuthMethod` is `GET`, query params are added to the URL, whereas when `AuthMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | `Dictionary<string, string>` |
-| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | Tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls). The default is true. | `Boolean` |
-| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `ClientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `ClientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `ClientId` specified here conflicts with the `ClientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| UseTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
+| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `ClientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `ClientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `ClientId` specified here conflicts with the `ClientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| UseTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
 | Endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is null. | `String` |
 | Environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is null. | `String` |
 | IdempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs. The default is true. | `Boolean` |
@@ -1920,7 +1920,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | LogLevel | This is an enum controlling the verbosity of the output from `Debug` (maximum) to `Error` (errors only). A special value of `None` will silence all logging. Note that the `LogLevel` is a static variable in the library and will thus not act independently between library instances. The default is `Error`. | `Enum` |
 | LoggerSink | The default ILoggerSink outputs messages to the debug console. This property allows the user to pipe the log messages to their own logging infrastructure. The default is `IO.Ably.DefaultLoggerSink`. | |
 | UseBinaryProtocol | If set to false, will forcibly disable the binary protocol (MessagePack). The binary protocol is used by default unless it is not supported. The default is true. Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency) | `Boolean` |
-| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
+| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
 | DefaultTokenParams | When a [TokenParams](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably TokenRequests](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -1928,17 +1928,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| Token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `Token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
+| Key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| Token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `Token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| AuthCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
 | AuthUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `String` |
 | AuthMethod | The HTTP verb to use for the request, either `GET` or `POST`. The default is `GET`. | `String` |
 | AuthHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. | `Object` |
 | AuthParams | A set of key value pair params to be added to any request made to the `AuthUrl`. When the `AuthMethod` is `GET`, query params are added to the URL, whereas when `AuthMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | `Object` |
-| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| TokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `AuthUrl` or `AuthCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | Tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls). The default is true. | `Boolean` |
-| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `ClientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `ClientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `ClientId` specified here conflicts with the `ClientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| UseTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
+| ClientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `ClientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `ClientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `ClientId` specified here conflicts with the `ClientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| UseTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
 | Endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is null. | `String` |
 | Environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is null. | `String` |
 | IdempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs. The default is true. | `Boolean` |
@@ -1946,7 +1946,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | transportParams | Optional. Can be used to pass in arbitrary connection parameters, such as [`heartbeatInterval`](/docs/connect#heartbeats) and [`remainPresentFor`](/docs/presence-occupancy/presence#unstable-connections) | `Object` |
 | LogLevel | This is an enum controlling the verbosity of the output from `LogDebug` (maximum) to `LogError` (errors only). A special value of `LogNone` will silence all logging. Note that the `LogLevel` is a static variable in the library and will thus not act independently between library instances. The default is `LogError`. | `Enum` |
 | UseBinaryProtocol | If set to false, will forcibly disable the binary protocol (MessagePack). The binary protocol is used by default unless it is not supported. The default is true. Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency) | `Boolean` |
-| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
+| QueryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
 | DefaultTokenParams | When a [TokenParams](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably TokenRequests](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -1954,17 +1954,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `NSURL` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`. The default is `GET`. | `String` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. | `Object` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | <If lang="objc">`NSArray<NSURLQueryItem *>`</If><If lang="swift">`[NSURLQueryItem]/Array<NSURLQueryItem>`</If> |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls). The default is true. | `Boolean` |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is nil. | `String` |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is nil. | `String` |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs. The default is true. | `Boolean` |
@@ -1974,7 +1974,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | logHandler | A `ARTLog` object can be specified to handle each line of log output. If `logHandler` is not specified, a default `ARTLog` instance is used. | `ARTLog *` |
 | useBinaryProtocol | Note: The binary protocol is currently not supported <If lang="swift">in Swift</If><If lang="objc">in Objective-C</If>. Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency) | `Boolean` |
 | logExceptionReportingUrl | Defaults to a string value for an Ably error reporting Data Source Name. | `String` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
 | defaultTokenParams | When a [TokenParams](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably TokenRequests](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -1982,17 +1982,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| :key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| :token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `:auth_url` or `:auth_callback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| :auth_callback | A proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter) which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `Proc` |
+| :key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| :token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `:auth_url` or `:auth_callback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| :auth_callback | A proc / lambda (called synchronously in REST and Realtime but does not block EventMachine in the latter) which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `Proc` |
 | :auth_url | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `String` |
 | :auth_method | The HTTP verb to use for the request, either `:get` or `:post`. The default is `:get`. | `Symbol` |
 | :auth_headers | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. | `Hash` |
 | :auth_params | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | `Hash` |
-| :token_details | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `:auth_url` or `:auth_callback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| :token_details | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `:auth_url` or `:auth_callback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | :tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls). The default is true. | `Boolean` |
-| :client_id | A client ID, used for identifying this client when publishing messages or for presence purposes. The `client_id` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `client_id` may also be implicit in a token used to instantiate the library; an error will be raised if a `client_id` specified here conflicts with the `client_id` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| :use_token_auth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `client_id` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
+| :client_id | A client ID, used for identifying this client when publishing messages or for presence purposes. The `client_id` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `client_id` may also be implicit in a token used to instantiate the library; an error will be raised if a `client_id` specified here conflicts with the `client_id` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| :use_token_auth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `client_id` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
 | :endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is nil. | `String` |
 | :environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is nil. | `String` |
 | :idempotent_rest_publishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs. The default is true. | `Boolean` |
@@ -2001,7 +2001,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | :log_level | Log level for the standard Logger that outputs to `STDOUT`. Can be set to `:fatal`, `:error`, `:warn`, `:info`, `:debug` or `:none`. Alternatively a [`Logger` severity constant](http://ruby-doc.org/stdlib-2.2.0/libdoc/logger/rdoc/Logger.html#class-Logger-label-Description) can be specified. The default is `:error`. | `Symbol`, [`Logger::SEVERITY`](http://ruby-doc.org/stdlib-2.2.0/libdoc/logger/rdoc/Logger.html#class-Logger-label-Description) |
 | :logger | A [Ruby `Logger`](http://ruby-doc.org/stdlib-1.9.3/libdoc/logger/rdoc/Logger.html) compatible object to handle each line of log output. If `logger` is not specified, `STDOUT` is used. The default is `STDOUT Logger`. | [Ruby `Logger`](http://ruby-doc.org/stdlib-1.9.3/libdoc/logger/rdoc/Logger.html) |
 | :use_binary_protocol | If set to false, will forcibly disable the binary protocol (MessagePack). The binary protocol is used by default unless it is not supported. The default is true. Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency) | `Boolean` |
-| :query_time | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
+| :query_time | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
 | :default_token_params | When a [TokenParams](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably TokenRequests](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -2009,17 +2009,17 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `String` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`. The default is `GET`. | `String` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. | Associative Array |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | Associative Array |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls). The default is true. | `Boolean` |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is null. | `String` |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is null. | `String` |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs. The default is true. | `Boolean` |
@@ -2028,7 +2028,7 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 | logLevel | A number controlling the verbosity of the output from 1 (minimum, errors only) to 4 (most verbose). The default is `Log::WARNING`. | `Integer` |
 | logHandler | A function to handle each line of log output. If handler is not specified, `console.log` is used. Note that the log level and log handler have global scope in the library and will therefore not act independently between library instances when multiple library instances exist concurrently. The default is `console.log`. | `Function` |
 | useBinaryProtocol | If set to false, will forcibly disable the binary protocol (MessagePack). The binary protocol is used by default unless it is not supported. The default is true. Note: The binary protocol is currently not supported in PHP. Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency) | `Boolean` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
 | defaultTokenParams | When a [TokenParams](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably TokenRequests](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -2036,24 +2036,24 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `auth_url` or `auth_callback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| auth_callback | A callable (eg a lambda) which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `auth_url` or `auth_callback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| auth_callback | A callable (eg a lambda) which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
 | auth_url | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `String` |
 | auth_method | The HTTP verb to use for the request, either `GET` or `POST`. The default is `GET`. | `String` |
 | auth_headers | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. | `Dict` |
 | auth_params | A set of key value pair params to be added to any request made to the `authUrl`. When the `auth_method` is `GET`, query params are added to the URL, whereas when `auth_method` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | `Object` |
-| token_details | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `auth_url` or `auth_callback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| token_details | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `auth_url` or `auth_callback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls). The default is true. | `Boolean` |
-| client_id | A client ID, used for identifying this client when publishing messages or for presence purposes. The `client_id` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `client_id` may also be implicit in a token used to instantiate the library; an error will be raised if a `client_id` specified here conflicts with the `client_id` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| use_token_auth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `client_id` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
+| client_id | A client ID, used for identifying this client when publishing messages or for presence purposes. The `client_id` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `client_id` may also be implicit in a token used to instantiate the library; an error will be raised if a `client_id` specified here conflicts with the `client_id` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| use_token_auth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `client_id` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is None. | `String` |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is None. | `String` |
 | idempotent_rest_publishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs. The default is true. | `Boolean` |
 | fallback_hosts | An array of fallback hosts to be used in the case of an error necessitating the use of an alternative host. When a custom environment is specified, the [fallback host functionality](https://faqs.ably.com/routing-around-network-and-dns-issues) is disabled. If your customer success manager has provided you with a set of custom fallback hosts, please specify them here. The default is `[a.ably-realtime.com, b.ably-realtime.com, c.ably-realtime.com, d.ably-realtime.com, e.ably-realtime.com]`. | `String []` |
 | transport_params | Optional. Can be used to pass in arbitrary connection parameters, such as [`heartbeatInterval`](/docs/connect#heartbeats) and [`remainPresentFor`](/docs/presence-occupancy/presence#unstable-connections) | `Dict` |
 | use_binary_protocol | If set to false, will forcibly disable the binary protocol (MessagePack). The binary protocol is used by default unless it is not supported. The default is true. Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency) | `Boolean` |
-| query_time | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
+| query_time | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
 | default_token_params | When a [TokenParams](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably TokenRequests](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -2062,24 +2062,24 @@ A `TokenRevocationFailureResult` contains information about the result of an uns
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/auth/basic) | `String` |
-| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
-| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
+| key | The full key string, as obtained from the [application dashboard](https://ably.com/dashboard). Use this option if you wish to use Basic authentication, or wish to be able to issue Ably Tokens without needing to defer to a separate entity to sign Ably TokenRequests. Read more about [Basic authentication](/docs/platform/auth/basic) | `String` |
+| token | An authenticated token. This can either be a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object, a [`TokenRequest`](/docs/api/realtime-sdk/types#token-request) object, or token string (obtained from the `token` property of a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) component of an Ably TokenRequest response, or a [JSON Web Token](https://tools.ietf.org/html/rfc7519) satisfying [the Ably requirements for JWTs](/docs/platform/auth/token/jwt)). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Read more about [Token authentication](/docs/platform/auth/token) | `String`, `TokenDetails` or `TokenRequest` |
+| authCallback | A function which is called when a new token is required. The role of the callback is to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). See [our authentication documentation](/docs/platform/auth) for details of the Ably TokenRequest format and associated API calls. | `Callable` |
 | authUrl | A URL that the library may use to obtain a fresh token, one of: an Ably Token string (in plain text format); a signed [`TokenRequest`](/docs/api/realtime-sdk/types#token-request); a [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) (in JSON format); an [Ably JWT](/docs/api/realtime-sdk/authentication#ably-jwt). For example, this can be used by a client to obtain signed Ably TokenRequests from an application server. | `String` |
 | authMethod | The HTTP verb to use for the request, either `GET` or `POST`. The default is `GET`. | `String` |
 | authHeaders | A set of key value pair headers to be added to any request made to the `authUrl`. Useful when an application requires these to be added to validate the request or implement the response. | `Map<String, String>` |
 | authParams | A set of key value pair params to be added to any request made to the `authUrl`. When the `authMethod` is `GET`, query params are added to the URL, whereas when `authMethod` is `POST`, the params are sent as URL encoded form data. Useful when an application require these to be added to validate the request or implement the response. | `Map<String, String>` |
-| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/auth/token) | `TokenDetails` |
+| tokenDetails | An authenticated [`TokenDetails`](/docs/api/realtime-sdk/types#token-details) object (most commonly obtained from an Ably Token Request response). This option is mostly useful for testing: since tokens are short-lived, in production you almost always want to use an authentication method that allows the client library to renew the token automatically when the previous one expires, such as `authUrl` or `authCallback`. Use this option if you wish to use Token authentication. Read more about [Token authentication](/docs/platform/auth/token) | `TokenDetails` |
 | tls | A boolean value, indicating whether or not a TLS ("SSL") secure connection should be used. An insecure connection cannot be used with Basic authentication as it would lead to a possible compromise of the private API key while in transit. [Find out more about TLS](https://faqs.ably.com/are-messages-sent-to-and-received-from-ably-securely-using-tls). The default is true. | `Boolean` |
-| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
-| useTokenAuth | When true, forces [Token authentication](/docs/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
+| clientId | A client ID, used for identifying this client when publishing messages or for presence purposes. The `clientId` can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a `clientId` may also be implicit in a token used to instantiate the library; an error will be raised if a `clientId` specified here conflicts with the `clientId` implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
+| useTokenAuth | When true, forces [Token authentication](/docs/platform/auth/token) to be used by the library. Please note that if a `clientId` is not specified in the [`ClientOptions`](/docs/api/realtime-sdk/types#client-options) or [`TokenParams`](/docs/api/realtime-sdk/types#token-params), then the Ably Token issued will be [anonymous](https://faqs.ably.com/authenticated-and-identified-clients). The default is false. | `Boolean` |
 | endpoint | Enables [enterprise customers](https://ably.com/pricing) to use their own custom endpoints, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is null. | `String` |
 | environment | Deprecated, use `endpoint`. Enables [enterprise customers](https://ably.com/pricing) to use their own custom environments, which support dedicated, isolated clusters and regional message routing and storage constraints. See our [platform customization guide](/docs/platform/account/enterprise-customization) for more details. The default is null. | `String` |
 | idempotentRestPublishing | When true, enables idempotent publishing by assigning a unique message ID client-side, allowing the Ably servers to discard automatic publish retries following a failure such as a network fault. Enabled by default in all current Ably SDKs. The default is true. | `Boolean` |
 | fallbackHosts | An array of fallback hosts to be used in the case of an error necessitating the use of an alternative host. When a custom environment is specified, the [fallback host functionality](https://faqs.ably.com/routing-around-network-and-dns-issues) is disabled. If your customer success manager has provided you with a set of custom fallback hosts, please specify them here. The default is `[a.ably-realtime.com, b.ably-realtime.com, c.ably-realtime.com, d.ably-realtime.com, e.ably-realtime.com]`. | `String []` |
 | transportParams | Optional. Can be used to pass in arbitrary connection parameters, such as [`heartbeatInterval`](/docs/connect#heartbeats) and [`remainPresentFor`](/docs/presence-occupancy/presence#unstable-connections) | `Map<String, String>` |
 | useBinaryProtocol | If set to false, will forcibly disable the binary protocol (MessagePack). The binary protocol is used by default unless it is not supported. The default is true. Find out more about the [benefits of binary encoding](https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency) | `Boolean` |
-| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
+| queryTime | If true, the library will query the Ably servers for the current time when [issuing TokenRequests](/docs/platform/auth/token) instead of relying on a locally-available time of day. Knowing the time accurately is needed to create valid signed Ably [TokenRequests](/docs/api/rest-sdk/authentication#token-request), so this option is useful for library instances on auth servers where for some reason the server clock cannot be kept synchronized through normal means, such as an [NTP daemon](https://en.wikipedia.org/wiki/Ntpd). The server is queried for the current time once per client library instance (which stores the offset from the local clock), so if using this option you should avoid instancing a new version of the library for each request. The default is false. | `Boolean` |
 | defaultTokenParams | When a [TokenParams](/docs/api/rest-sdk/types#token-params) object is provided, it will override the client library defaults when issuing new [Ably Tokens](/docs/api/realtime-sdk/authentication#token-details) or [Ably TokenRequests](/docs/api/rest-sdk/authentication#token-request) | [`TokenParams`](/docs/api/rest-sdk/types#token-params) |
 
 </If>
@@ -2215,32 +2215,32 @@ Individual client libraries may support either instancing a `CipherParams` direc
 
 <If lang="javascript,nodejs">
 
-`TokenParams` is a plain JavaScript object and is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following attributes can be defined on the object:
+`TokenParams` is a plain JavaScript object and is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following attributes can be defined on the object:
 
 </If>
 <If lang="ruby">
 
-`TokenParams` is a Hash object and is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following key symbol values can be added to the Hash:
+`TokenParams` is a Hash object and is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following key symbol values can be added to the Hash:
 
 </If>
 <If lang="python">
 
-`TokenParams` is a Dict and is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following keys-value pairs can be added to the Dict:
+`TokenParams` is a Dict and is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following keys-value pairs can be added to the Dict:
 
 </If>
 <If lang="php">
 
-`TokenParams` is an Associative Array and is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following named keys and values can be added to the Associative Array:
+`TokenParams` is an Associative Array and is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). The following named keys and values can be added to the Associative Array:
 
 </If>
 <If lang="java,csharp">
 
-`TokenParams` is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
+`TokenParams` is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
 
 </If>
 <If lang="objc,swift">
 
-`ARTTokenParams` is used in the parameters of [token authentication](/docs/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
+`ARTTokenParams` is used in the parameters of [token authentication](/docs/platform/auth/token) requests, corresponding to the desired attributes of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details).
 
 </If>
 
@@ -2248,8 +2248,8 @@ Individual client libraries may support either instancing a `CipherParams` direc
 
 | Parameter | Description | Type |
 |-----------|-------------|------|
-| <If lang="javascript,nodejs,flutter,php,objc,swift,java,python">capability</If><If lang="csharp,go">Capability</If><If lang="ruby">:capability</If> | JSON stringified capability of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) request is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. [Find our more about how to use capabilities to manage access privileges for clients](/docs/auth/capabilities). | <If lang="javascript,nodejs,flutter,php,objc,swift,java,python,ruby,go">`String`</If><If lang="csharp">`Capability`</If> |
-| <If lang="javascript,nodejs,flutter,php,objc,swift,java">clientId</If><If lang="csharp,go">ClientId</If><If lang="python">client_id</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,flutter,php,objc,swift,java">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,flutter,php,objc,swift,java">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,flutter,php,objc,swift,java">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> specified here conflicts with the <If lang="javascript,nodejs,flutter,php,objc,swift,java">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> implicit in the token. [Find out more about client identities](/docs/auth/identified-clients) | `String` |
+| <If lang="javascript,nodejs,flutter,php,objc,swift,java,python">capability</If><If lang="csharp,go">Capability</If><If lang="ruby">:capability</If> | JSON stringified capability of the [Ably Token](/docs/api/realtime-sdk/authentication#token-details). If the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) request is successful, the capability of the returned [Ably Token](/docs/api/realtime-sdk/authentication#token-details) will be the intersection of this capability with the capability of the issuing key. [Find our more about how to use capabilities to manage access privileges for clients](/docs/platform/auth/capabilities). | <If lang="javascript,nodejs,flutter,php,objc,swift,java,python,ruby,go">`String`</If><If lang="csharp">`Capability`</If> |
+| <If lang="javascript,nodejs,flutter,php,objc,swift,java">clientId</If><If lang="csharp,go">ClientId</If><If lang="python">client_id</If><If lang="ruby">:client_id</If> | A client ID, used for identifying this client when publishing messages or for presence purposes. The <If lang="javascript,nodejs,flutter,php,objc,swift,java">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> can be any non-empty string. This option is primarily intended to be used in situations where the library is instantiated with a key; note that a <If lang="javascript,nodejs,flutter,php,objc,swift,java">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> may also be implicit in a token used to instantiate the library; an error will be raised if a <If lang="javascript,nodejs,flutter,php,objc,swift,java">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> specified here conflicts with the <If lang="javascript,nodejs,flutter,php,objc,swift,java">`clientId`</If><If lang="ruby,python">`client_id`</If><If lang="csharp,go">`ClientId`</If> implicit in the token. [Find out more about client identities](/docs/platform/auth/identified-clients) | `String` |
 | <If lang="javascript,nodejs,flutter,php,objc,swift,java,python">nonce</If><If lang="csharp,go">Nonce</If><If lang="ruby">:nonce</If> | An optional opaque nonce string of at least 16 characters to ensure uniqueness of this request. Any subsequent request using the same nonce will be rejected. | `String` |
 | <If lang="javascript,nodejs,flutter,php,objc,swift,java,python">timestamp</If><If lang="csharp,go">Timestamp</If><If lang="ruby">:timestamp</If> | <If lang="javascript,nodejs,flutter,php,go,java,python">The timestamp (in milliseconds since the epoch)</If><If lang="ruby,objc,swift,csharp">The timestamp</If> of this request. `timestamp`, in conjunction with the `nonce`, is used to prevent requests for [Ably Token](/docs/api/realtime-sdk/authentication#token-details) from being replayed. | <If lang="javascript,nodejs,php,objc,swift,python">`Integer`</If><If lang="java">`Long Integer`</If><If lang="ruby">`Time`</If><If lang="objc,swift">`NSDate`</If><If lang="csharp">`DateTimeOffset`</If><If lang="flutter">`DateTime`</If> |
 | <If lang="javascript,nodejs,flutter,php,objc,swift,java,python">ttl</If><If lang="csharp,go">Ttl</If><If lang="ruby">:ttl</If> | Requested time to live for the [Ably Token](/docs/api/realtime-sdk/authentication#token-details) being created <If lang="javascript,nodejs,flutter,php,go,java,python">in milliseconds</If><If lang="ruby">in seconds</If><If lang="objc,swift">as a `NSTimeInterval`</If><If lang="csharp,go">as a `TimeSpan`.</If> When omitted, the Ably REST API default of 60 minutes is applied by Ably. The default is 1 hour. | <If lang="javascript,nodejs,flutter,php,python">`Integer` (milliseconds)</If><If lang="ruby">`Integer` (seconds)</If><If lang="objc,swift">`NSTimeInterval`</If><If lang="java">`Long Integer`</If><If lang="csharp">`TimeSpan`</If> |
diff --git a/src/pages/docs/api/token-request-spec.mdx b/src/pages/docs/api/token-request-spec.mdx
index 5f447a50d4..52143f1526 100644
--- a/src/pages/docs/api/token-request-spec.mdx
+++ b/src/pages/docs/api/token-request-spec.mdx
@@ -9,7 +9,7 @@ redirect_from:
   - /docs/rest-api/versions/v1.0/token-request-spec
 ---
 
-The [Ably REST and Realtime client libraries](https://ably.com/download/) aim to make things as simple as possible so it is not necessary to understand all of the details of how to interact with the service and issue tokens for clients. If you wish to issue Ably-compatible tokens or [Ably TokenRequests](/docs/api/realtime-sdk/types#token-request), we recommend you start with the [client library authentication documentation](/docs/auth).
+The [Ably REST and Realtime client libraries](https://ably.com/download/) aim to make things as simple as possible so it is not necessary to understand all of the details of how to interact with the service and issue tokens for clients. If you wish to issue Ably-compatible tokens or [Ably TokenRequests](/docs/api/realtime-sdk/types#token-request), we recommend you start with the [client library authentication documentation](/docs/platform/auth).
 
 However, if you are using the [REST API token endpoint directly](/docs/api/rest-api/#request-token), or if you are creating Ably `TokenRequests` without the use of our client libraries, then the following specification will give you an in-depth understanding of how getting Ably Tokens works.
 
@@ -81,9 +81,9 @@ The following capability operations are available for API keys and issued tokens
 | channel-metadata | Can get metadata for a channel, and enumerate channels |
 | privileged-headers | Can set data in the privileged section of the [message extras](/docs/api/realtime-sdk/messages#extras) |
 
-Read the [capabilities docs](/docs/auth/capabilities) to get a more thorough overview of how capabilities can be used to secure your application.
+Read the [capabilities docs](/docs/platform/auth/capabilities) to get a more thorough overview of how capabilities can be used to secure your application.
 
-While most of these capabilities need to be enabled for the resource you're using them with, as described in [resource names and wildcards](/docs/auth/capabilities#wildcards), there are exceptions. The `stats` permission only does something when attached to the wildcard resource `'*'`, or a resource that contains that as a subset, such as `'[*]*'`, since stats are app-wide.
+While most of these capabilities need to be enabled for the resource you're using them with, as described in [resource names and wildcards](/docs/platform/auth/capabilities#wildcards), there are exceptions. The `stats` permission only does something when attached to the wildcard resource `'*'`, or a resource that contains that as a subset, such as `'[*]*'`, since stats are app-wide.
 
 The `channel-metadata` permission works both ways. When associated with a specific channel or set of channels it allows you to [query the metadata of a channel](/docs/metadata-stats/metadata/rest) to request its status. When associated with the wildcard resource `'*'` it takes on an additional meaning: as well as allowing channel status requests for all channels, it also allows you to [enumerate all active channels](/docs/metadata-stats/metadata/rest#enumerate).
 
diff --git a/src/pages/docs/channels/index.mdx b/src/pages/docs/channels/index.mdx
index 72b2a7cb2e..1a660b29b0 100644
--- a/src/pages/docs/channels/index.mdx
+++ b/src/pages/docs/channels/index.mdx
@@ -26,7 +26,7 @@ redirect_from:
   - /docs/general/versions/v0.8/channel-rules-namespaces
 ---
 
-Channels are used to separate messages into different topics. They are the building block of creating a realtime application using the publish-subscribe pattern. Channels are also the unit of security and scalability. Clients should only ever be provided the [capabilities](/docs/auth/capabilities) for channels that they should have access to.
+Channels are used to separate messages into different topics. They are the building block of creating a realtime application using the publish-subscribe pattern. Channels are also the unit of security and scalability. Clients should only ever be provided the [capabilities](/docs/platform/auth/capabilities) for channels that they should have access to.
 
 [Messages](/docs/messages) contain the data that a client is communicating, such as the contents of an individual chat message, or an event that has occurred, such as updated financial information.
 
@@ -151,17 +151,17 @@ A namespace is the first part of a channel name up to the first colon (`:`). If
 
 Channel namespaces have the same restrictions as those listed for channels. Additionally they cannot contain the wildcard character `*`.
 
-Use channel namespaces to apply operations to all channels within that group, such as [capabilities](/docs/auth/capabilities), [channel rules](#rules) and [integrations](/docs/platform/integrations).
+Use channel namespaces to apply operations to all channels within that group, such as [capabilities](/docs/platform/auth/capabilities), [channel rules](#rules) and [integrations](/docs/platform/integrations).
 
 <Aside data-type="note">
-Namespaces are not required to refer to a group of channels within a [capability](/docs/auth/capabilities). A resource specifier, such as `foo:*`, a glob expression, will match a channel named `foo:bar`, even without a `foo` namespace.
+Namespaces are not required to refer to a group of channels within a [capability](/docs/platform/auth/capabilities). A resource specifier, such as `foo:*`, a glob expression, will match a channel named `foo:bar`, even without a `foo` namespace.
 </Aside>
 
 ## Publishing and subscribing <a id="pub-sub"/>
 
 Clients [subscribe](/docs/pub-sub#subscribe) to a channel to receive the messages published to it. Clients can subscribe to all messages, or only messages identified by specific names.
 
-[Publishing](/docs/pub-sub#publish) messages to a channel is how clients communicate with one another. Any subscribers will receive published messages as long as they are subscribed and have the `subscribe` [capability](/docs/auth/capabilities) for that channel.
+[Publishing](/docs/pub-sub#publish) messages to a channel is how clients communicate with one another. Any subscribers will receive published messages as long as they are subscribed and have the `subscribe` [capability](/docs/platform/auth/capabilities) for that channel.
 
 ## Channel options <a id="options"/>
 
@@ -190,7 +190,7 @@ The channel rules related to security and client identity are:
 
 | Rule | Description |
 |------|-------------|
-| Identified | If enabled, clients will not be permitted to use (including to attach, publish, or subscribe) matching channels unless they are [identified](/docs/auth/identified-clients) (they have an assigned client ID). Anonymous clients are not permitted to join these channels. Find out more about [authenticated and identified clients](/docs/auth/identified-clients). |
+| Identified | If enabled, clients will not be permitted to use (including to attach, publish, or subscribe) matching channels unless they are [identified](/docs/platform/auth/identified-clients) (they have an assigned client ID). Anonymous clients are not permitted to join these channels. Find out more about [authenticated and identified clients](/docs/platform/auth/identified-clients). |
 | TLS only | If enabled, only clients who have connected to Ably over TLS will be allowed to use matching channels. By default all of Ably's client libraries use TLS when communicating with Ably over REST or when using Realtime transports such as Websockets. |
 
 The channel rules related to enabling features are:
diff --git a/src/pages/docs/channels/options/encryption.mdx b/src/pages/docs/channels/options/encryption.mdx
index 645114aeb5..47e4d40a05 100644
--- a/src/pages/docs/channels/options/encryption.mdx
+++ b/src/pages/docs/channels/options/encryption.mdx
@@ -30,7 +30,7 @@ Disabling TLS is strongly discouraged and is enabled by default in all client li
 
 Unencrypted communication with Ably is **disallowed** if any of the following conditions are met:
 
-* You attempt to use [Basic Authentication](/docs/auth/basic) and thus transmit a private API key over an unencrypted connection. You are only permitted to use unencrypted connections with [Token Authentication](/docs/auth/token) as tokens expire, limiting the impact of token interception.
+* You attempt to use [Basic Authentication](/docs/platform/auth/basic) and thus transmit a private API key over an unencrypted connection. You are only permitted to use unencrypted connections with [Token Authentication](/docs/platform/auth/token) as tokens expire, limiting the impact of token interception.
 
 * You have specified that TLS is required in your [app settings](/docs/platform/account/app/settings).
 
diff --git a/src/pages/docs/channels/options/index.mdx b/src/pages/docs/channels/options/index.mdx
index 70088ffd9f..59ad450862 100644
--- a/src/pages/docs/channels/options/index.mdx
+++ b/src/pages/docs/channels/options/index.mdx
@@ -265,7 +265,7 @@ const channel = realtime.channels.get('{{RANDOM_CHANNEL_NAME}}', channelOpts);
 As `occupancy` requires a channel subscription, it is only available when using the realtime interface of an Ably SDK.
 
 <Aside data-type="important">
-Clients require the `channel-metadata` [capability](/docs/auth/capabilities) to subscribe to occupancy metrics.
+Clients require the `channel-metadata` [capability](/docs/platform/auth/capabilities) to subscribe to occupancy metrics.
 </Aside>
 
 #### Subscribe to occupancy events <a id="subscribe-occupancy"/>
@@ -463,7 +463,7 @@ The available set of channel mode flags are:
 | `ANNOTATION_PUBLISH` | Can publish annotations to messages on the channel. | Yes |
 | `ANNOTATION_SUBSCRIBE` | Can subscribe to individual annotations on the channel. | No |
 
-The set of modes available to a client is determined by the set of [capabilities](/docs/auth/capabilities) granted by their token or API key.
+The set of modes available to a client is determined by the set of [capabilities](/docs/platform/auth/capabilities) granted by their token or API key.
 
 The modes granted by each capability are:
 
diff --git a/src/pages/docs/channels/states.mdx b/src/pages/docs/channels/states.mdx
index 32dfca1ff7..e9e216204b 100644
--- a/src/pages/docs/channels/states.mdx
+++ b/src/pages/docs/channels/states.mdx
@@ -626,7 +626,7 @@ channel.Attach(context.Background())
 
 ### Fatal channel errors <a id="fatal-errors"/>
 
-Some classes of errors are fatal. These cause the channel to move to the `FAILED` state. Ably SDKs will not attempt any automatic recovery actions. For example, when attempting to attach to a channel, with a token that doesn't have the `subscribe` [capability](/docs/auth/capabilities) for that channel, will cause that channel to enter the `FAILED` state.
+Some classes of errors are fatal. These cause the channel to move to the `FAILED` state. Ably SDKs will not attempt any automatic recovery actions. For example, when attempting to attach to a channel, with a token that doesn't have the `subscribe` [capability](/docs/platform/auth/capabilities) for that channel, will cause that channel to enter the `FAILED` state.
 
 Whilst fatal errors won't get better on their own, they are fixable. For example, if a channel goes into the `FAILED` state due to the client not having the right capabilities to attach to it, that client could call [`authorize()`](/docs/api/realtime-sdk/authentication#authorize) to obtain a new token which does have the right capabilities, then call [`attach()`](/docs/api/realtime-sdk/channels#attach) on the channel. The library will not automatically reattach in the `FAILED` state, however explicit calls to [`attach()`](/docs/api/realtime-sdk/channels#attach) will make the client try again.
 
diff --git a/src/pages/docs/chat/api/javascript/chat-client.mdx b/src/pages/docs/chat/api/javascript/chat-client.mdx
index d4591e335e..c1f6c201fd 100644
--- a/src/pages/docs/chat/api/javascript/chat-client.mdx
+++ b/src/pages/docs/chat/api/javascript/chat-client.mdx
@@ -17,7 +17,7 @@ const chatClient = new ChatClient(realtimeClient, { logLevel: LogLevel.Error });
 ```
 </Code>
 
-An API key is required to authenticate with Ably. API keys are used either to authenticate directly with Ably using basic authentication, or to generate tokens for untrusted clients using [JWT authentication](/docs/auth/token#jwt).
+An API key is required to authenticate with Ably. API keys are used either to authenticate directly with Ably using basic authentication, or to generate tokens for untrusted clients using [JWT authentication](/docs/platform/auth/token#jwt).
 
 <Aside data-type='important'>
 Basic authentication should never be used on the client-side in production, as it exposes your Ably API key. Instead, use JWT authentication.
diff --git a/src/pages/docs/chat/api/javascript/message-reactions.mdx b/src/pages/docs/chat/api/javascript/message-reactions.mdx
index d3abc2984d..bd968d018e 100644
--- a/src/pages/docs/chat/api/javascript/message-reactions.mdx
+++ b/src/pages/docs/chat/api/javascript/message-reactions.mdx
@@ -265,7 +265,7 @@ The `subscribeRaw()` method takes the following parameters:
 | name | Required | The reaction identifier. | String |
 | count | Optional | The count for Multiple type reactions. | Number |
 | clientId | Required | The client ID who sent the reaction. | String |
-| userClaim | Optional | The user claim attached to this reaction by the server. Only present if the user's [JWT](/docs/auth/token#jwt) contained a claim for the room. | String or Undefined |
+| userClaim | Optional | The user claim attached to this reaction by the server. Only present if the user's [JWT](/docs/platform/auth/token#jwt) contained a claim for the room. | String or Undefined |
 
 </Table>
 
diff --git a/src/pages/docs/chat/api/javascript/message.mdx b/src/pages/docs/chat/api/javascript/message.mdx
index 1b41d99977..91aa7d8718 100644
--- a/src/pages/docs/chat/api/javascript/message.mdx
+++ b/src/pages/docs/chat/api/javascript/message.mdx
@@ -16,7 +16,7 @@ The `Message` interface has the following properties:
 | --- | --- | --- |
 | serial | The unique identifier of the message. | String |
 | clientId | The client ID of the user who created the message. | String |
-| userClaim | The user claim attached to this message by the server. Only present if the publishing user's [JWT](/docs/auth/token#jwt) contained a claim for the room in which this message was published. | String or Undefined |
+| userClaim | The user claim attached to this message by the server. Only present if the publishing user's [JWT](/docs/platform/auth/token#jwt) contained a claim for the room in which this message was published. | String or Undefined |
 | text | The text content of the message. | String |
 | timestamp | The timestamp at which the message was created. | Date |
 | metadata | Extra information attached to the message for features like animations or linking to external resources. Always set; empty object if no metadata was provided. | <Table id='MessageMetadata'/> |
diff --git a/src/pages/docs/chat/api/javascript/presence.mdx b/src/pages/docs/chat/api/javascript/presence.mdx
index 0282851a8e..0c8c9250aa 100644
--- a/src/pages/docs/chat/api/javascript/presence.mdx
+++ b/src/pages/docs/chat/api/javascript/presence.mdx
@@ -265,7 +265,7 @@ The `subscribe()` method takes the following parameters:
 | Property | Description | Type |
 | --- | --- | --- |
 | clientId | The client ID of the present user. | String |
-| userClaim | The user claim attached to this presence event by the server. Only present if the user's [JWT](/docs/auth/token#jwt) contained a claim for the room. | String or Undefined |
+| userClaim | The user claim attached to this presence event by the server. Only present if the user's [JWT](/docs/platform/auth/token#jwt) contained a claim for the room. | String or Undefined |
 | connectionId | The connection ID of the present user. | String |
 | data | The presence data associated with the user. | <Table id='PresenceData'/> or Undefined |
 | extras | Additional data included with the presence message. | JsonObject or Undefined |
diff --git a/src/pages/docs/chat/api/javascript/room-reactions.mdx b/src/pages/docs/chat/api/javascript/room-reactions.mdx
index 005eb394a9..6227f8cd1d 100644
--- a/src/pages/docs/chat/api/javascript/room-reactions.mdx
+++ b/src/pages/docs/chat/api/javascript/room-reactions.mdx
@@ -110,7 +110,7 @@ The `subscribe()` method takes the following parameters:
 | --- | --- | --- |
 | name | The name of the reaction (e.g., an emoji). | String |
 | clientId | The client ID of the user who sent the reaction. | String |
-| userClaim | The user claim attached to this reaction by the server. Only present if the user's [JWT](/docs/auth/token#jwt) contained a claim for the room. | String or Undefined |
+| userClaim | The user claim attached to this reaction by the server. Only present if the user's [JWT](/docs/platform/auth/token#jwt) contained a claim for the room. | String or Undefined |
 | metadata | Additional metadata included with the reaction. Empty object if none provided. | JsonObject |
 | headers | Additional information from Ably message extras. Empty object if none provided. | Headers |
 | createdAt | When the reaction was sent. | Date |
diff --git a/src/pages/docs/chat/api/javascript/typing.mdx b/src/pages/docs/chat/api/javascript/typing.mdx
index 37d500c009..0837ccedb3 100644
--- a/src/pages/docs/chat/api/javascript/typing.mdx
+++ b/src/pages/docs/chat/api/javascript/typing.mdx
@@ -29,7 +29,7 @@ The `Typing` interface has the following properties:
 | Property | Description | Type |
 | --- | --- | --- |
 | clientId | The client ID of the typing user. | String |
-| userClaim | The user claim attached to this typing event by the server. Only present if the user's [JWT](/docs/auth/token#jwt) contained a claim for the room. | String or Undefined |
+| userClaim | The user claim attached to this typing event by the server. Only present if the user's [JWT](/docs/platform/auth/token#jwt) contained a claim for the room. | String or Undefined |
 
 </Table>
 
@@ -134,7 +134,7 @@ The `subscribe()` method takes the following parameters:
 | --- | --- | --- |
 | clientId | The client ID whose typing state changed. | String |
 | type | Whether the user started or stopped typing. | <Table id='TypingEventType'/> |
-| userClaim | The user claim attached to this typing event by the server. Only present if the user's [JWT](/docs/auth/token#jwt) contained a claim for the room. | String or Undefined |
+| userClaim | The user claim attached to this typing event by the server. Only present if the user's [JWT](/docs/platform/auth/token#jwt) contained a claim for the room. | String or Undefined |
 
 </Table>
 
diff --git a/src/pages/docs/chat/authentication.mdx b/src/pages/docs/chat/authentication.mdx
index e122cef7a7..6b7c020b66 100644
--- a/src/pages/docs/chat/authentication.mdx
+++ b/src/pages/docs/chat/authentication.mdx
@@ -296,5 +296,5 @@ await realtimeClient.auth.authorize();
 ```
 </Code>
 
-- To immediately remove access, [revoke issued tokens](/docs/auth/revocation).
-- If your capability JSON is too large for JWT or must remain confidential, use native [Ably Tokens](/docs/auth/token/ably-tokens).
+- To immediately remove access, [revoke issued tokens](/docs/platform/auth/revocation).
+- If your capability JSON is too large for JWT or must remain confidential, use native [Ably Tokens](/docs/platform/auth/token/ably-tokens).
diff --git a/src/pages/docs/chat/getting-started/android.mdx b/src/pages/docs/chat/getting-started/android.mdx
index dd354c2a65..5fa82f3630 100644
--- a/src/pages/docs/chat/getting-started/android.mdx
+++ b/src/pages/docs/chat/getting-started/android.mdx
@@ -66,7 +66,7 @@ ably login
 
 Replace the contents of your `MainActivity.kt` file with the following code to set up the Ably client.
 
-Note that this is for example purposes only. In production, you should use [token authentication](/docs/auth/token) to avoid exposing your API keys publicly, the [`clientId`](/docs/auth/identified-clients) is used to identify the client:
+Note that this is for example purposes only. In production, you should use [token authentication](/docs/platform/auth/token) to avoid exposing your API keys publicly, the [`clientId`](/docs/platform/auth/identified-clients) is used to identify the client:
 
 <Code>
 ```android
@@ -963,7 +963,7 @@ class MainActivity : ComponentActivity() {
 
 Continue to explore the documentation with Kotlin as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Read more about using [rooms](/docs/chat/rooms?lang=kotlin) and sending [messages](/docs/chat/rooms/messages?lang=kotlin).
 * Find out more regarding [presence](/docs/chat/rooms/presence?lang=kotlin).
 * Read into pulling messages from [history](/docs/chat/rooms/history?lang=kotlin) and providing context to new joiners.
diff --git a/src/pages/docs/chat/getting-started/javascript.mdx b/src/pages/docs/chat/getting-started/javascript.mdx
index 1795696bee..e431222c05 100644
--- a/src/pages/docs/chat/getting-started/javascript.mdx
+++ b/src/pages/docs/chat/getting-started/javascript.mdx
@@ -84,7 +84,7 @@ ably login
 
 Clients establish a connection with Ably when they instantiate an SDK. This enables them to send and receive messages in realtime across channels.
 
-Create an `index.ts` file in your project and add the following function to instantiate a realtime client with the Pub/Sub SDK and then pass that client into the Chat SDK constructor. Provide an API key and a [`clientId`](/docs/auth/identified-clients) to identify the client. In production, use [token authentication](/docs/auth/token) so that your API keys are not exposed publicly.
+Create an `index.ts` file in your project and add the following function to instantiate a realtime client with the Pub/Sub SDK and then pass that client into the Chat SDK constructor. Provide an API key and a [`clientId`](/docs/platform/auth/identified-clients) to identify the client. In production, use [token authentication](/docs/platform/auth/token) so that your API keys are not exposed publicly.
 
 <Code>
 ```javascript
@@ -297,7 +297,7 @@ setTimeout(() => realtimeClient.close(), 10000);
 
 Continue to explore the documentation with JavaScript as the selected language:
 
-* Understand [token authentication](/docs/auth/token?lang=javascript) before going to production.
+* Understand [token authentication](/docs/platform/auth/token?lang=javascript) before going to production.
 * Read more about using [rooms](/docs/chat/rooms?lang=javascript) and sending [messages](/docs/chat/rooms/messages?lang=javascript).
 * Find out more regarding [presence](/docs/chat/rooms/presence?lang=javascript).
 * Read into pulling messages from [history](/docs/chat/rooms/history?lang=javascript) and providing context to new joiners.
diff --git a/src/pages/docs/chat/getting-started/jvm.mdx b/src/pages/docs/chat/getting-started/jvm.mdx
index abb15b89e0..a9cc57bdb2 100644
--- a/src/pages/docs/chat/getting-started/jvm.mdx
+++ b/src/pages/docs/chat/getting-started/jvm.mdx
@@ -83,7 +83,7 @@ Clients establish a connection with Ably when they instantiate an SDK. This enab
 
 Add the following code to the `App.kt` file created by `gradle init` set up the Ably client.
 
-Note that this is for example purposes only. In production, you should use [token authentication](/docs/auth/token) to avoid exposing your API keys publicly. The [`clientId`](/docs/auth/identified-clients) is used to identify the client when using an API key:
+Note that this is for example purposes only. In production, you should use [token authentication](/docs/platform/auth/token) to avoid exposing your API keys publicly. The [`clientId`](/docs/platform/auth/identified-clients) is used to identify the client when using an API key:
 
 <Code>
 ```kotlin
@@ -617,7 +617,7 @@ This demonstrates proper resource management and graceful shutdown of the chat c
 
 Continue to explore the documentation with Kotlin as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Read more about using [rooms](/docs/chat/rooms?lang=kotlin) and sending [messages](/docs/chat/rooms/messages?lang=kotlin).
 * Find out more regarding [presence](/docs/chat/rooms/presence?lang=kotlin).
 * Read into pulling messages from [history](/docs/chat/rooms/history?lang=kotlin) and providing context to new joiners.
diff --git a/src/pages/docs/chat/getting-started/react-native.mdx b/src/pages/docs/chat/getting-started/react-native.mdx
index e06c4c6a38..0ba2a94b27 100644
--- a/src/pages/docs/chat/getting-started/react-native.mdx
+++ b/src/pages/docs/chat/getting-started/react-native.mdx
@@ -75,7 +75,7 @@ ably login
 
 The Ably Pub/Sub SDK and the Ably Chat SDK expose React hooks and context providers to make it easier to use them in your React Native components. The [`AblyProvider`](/docs/getting-started/react-hooks#ably-provider) and [`ChatClientProvider`](https://sdk.ably.com/builds/ably/ably-chat-js/main/typedoc/functions/chat-react.ChatClientProvider.html) should be used at the top level of your application, typically in `App.tsx`. These are required when working with the [`useChatConnection`](https://sdk.ably.com/builds/ably/ably-chat-js/main/typedoc/functions/chat-react.useChatConnection.html) hook and [`ChatRoomProvider`](https://sdk.ably.com/builds/ably/ably-chat-js/main/typedoc/functions/chat-react.ChatRoomProvider.html) exposed by Ably Chat.
 
-In production, you should use [token authentication](/docs/auth/token) to avoid exposing your API keys publicly, the [`clientId`](/docs/auth/identified-clients) is used to identify the client.
+In production, you should use [token authentication](/docs/platform/auth/token) to avoid exposing your API keys publicly, the [`clientId`](/docs/platform/auth/identified-clients) is used to identify the client.
 
 Replace the contents of your `App.tsx` file with the following code to set up the providers:
 
@@ -938,7 +938,7 @@ const handleDisconnect = () => {
 
 Continue to explore the documentation with React Native as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Read more about using [rooms](/docs/chat/rooms?lang=react) and sending [messages](/docs/chat/rooms/messages?lang=react).
 * Find out more regarding [presence](/docs/chat/rooms/presence?lang=react).
 * Read into pulling messages from [history](/docs/chat/rooms/history?lang=react) and providing context to new joiners.
diff --git a/src/pages/docs/chat/getting-started/react-ui-kit.mdx b/src/pages/docs/chat/getting-started/react-ui-kit.mdx
index cea08e6ee1..73fd02ca34 100644
--- a/src/pages/docs/chat/getting-started/react-ui-kit.mdx
+++ b/src/pages/docs/chat/getting-started/react-ui-kit.mdx
@@ -142,7 +142,7 @@ In your main entry file (e.g. `main.tsx`), replace the content with the followin
 
 The components you make throughout this guide will be wrapped in these providers to ensure they have access to the necessary context.
 
-In production, you should use [token authentication](/docs/auth/token) to avoid exposing your API keys publicly, the [`clientId`](/docs/auth/identified-clients) is used to identify the client.
+In production, you should use [token authentication](/docs/platform/auth/token) to avoid exposing your API keys publicly, the [`clientId`](/docs/platform/auth/identified-clients) is used to identify the client.
 
 ### Provider responsibilities <a id="provider-responsibilities"/>
 
@@ -555,7 +555,7 @@ The UI Kit is experimental and highly likely to change in future releases.
 
 Continue to explore the documentation with React as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Read more about using [rooms](/docs/chat/rooms?lang=react) and sending [messages](/docs/chat/rooms/messages?lang=react).
 * Find out more regarding [presence](/docs/chat/rooms/presence?lang=react).
 * Read into pulling messages from [history](/docs/chat/rooms/history?lang=react) and providing context to new joiners.
diff --git a/src/pages/docs/chat/getting-started/react.mdx b/src/pages/docs/chat/getting-started/react.mdx
index 041442bd72..ab44bf8b1e 100644
--- a/src/pages/docs/chat/getting-started/react.mdx
+++ b/src/pages/docs/chat/getting-started/react.mdx
@@ -108,7 +108,7 @@ import {
 
 The Ably Pub/Sub SDK and the Ably Chat SDK expose React hooks and context providers to make it easier to use them in your React components. The [`AblyProvider`](/docs/getting-started/react-hooks#ably-provider) and [`ChatClientProvider`](https://sdk.ably.com/builds/ably/ably-chat-js/main/typedoc/functions/chat-react.ChatClientProvider.html) should be used at the top level of your application, typically in `main.tsx`. These are required when working with the [`useChatConnection`](https://sdk.ably.com/builds/ably/ably-chat-js/main/typedoc/functions/chat-react.useChatConnection.html) hook and [`ChatRoomProvider`](https://sdk.ably.com/builds/ably/ably-chat-js/main/typedoc/functions/chat-react.ChatRoomProvider.html) exposed by Ably Chat.
 
-In production, you should use [token authentication](/docs/auth/token) to avoid exposing your API keys publicly, the [`clientId`](/docs/auth/identified-clients) is used to identify the client.
+In production, you should use [token authentication](/docs/platform/auth/token) to avoid exposing your API keys publicly, the [`clientId`](/docs/platform/auth/identified-clients) is used to identify the client.
 
 Replace the contents of your `src/main.tsx` file with the following code to set up the providers:
 
@@ -935,7 +935,7 @@ This will close the connection to Ably and clean up any associated resources.
 
 Continue to explore the documentation with React as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Read more about using [rooms](/docs/chat/rooms?lang=react) and sending [messages](/docs/chat/rooms/messages?lang=react).
 * Find out more regarding [presence](/docs/chat/rooms/presence?lang=react).
 * Read into pulling messages from [history](/docs/chat/rooms/history?lang=react) and providing context to new joiners.
diff --git a/src/pages/docs/chat/getting-started/swift-async-sequence.mdx b/src/pages/docs/chat/getting-started/swift-async-sequence.mdx
index 03089809c3..04049750c9 100644
--- a/src/pages/docs/chat/getting-started/swift-async-sequence.mdx
+++ b/src/pages/docs/chat/getting-started/swift-async-sequence.mdx
@@ -62,7 +62,7 @@ Create a new iOS project with SwiftUI. For detailed instructions, refer to the [
 
 Replace the contents of your `ContentView.swift` file with the following code to set up the Ably client:
 
-Note that this is for example purposes only. In production, you should use [token authentication](/docs/auth/token) to avoid exposing your API keys publicly, the [`clientId`](/docs/auth/identified-clients) is used to identify the client:
+Note that this is for example purposes only. In production, you should use [token authentication](/docs/platform/auth/token) to avoid exposing your API keys publicly, the [`clientId`](/docs/platform/auth/identified-clients) is used to identify the client:
 
 <Code>
 ```swift
@@ -1241,7 +1241,7 @@ struct ContentView: View {
 
 Continue to explore the documentation with Swift as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Read more about using [rooms](/docs/chat/rooms?lang=swift) and sending [messages](/docs/chat/rooms/messages?lang=swift).
 * Find out more regarding [presence](/docs/chat/rooms/presence?lang=swift).
 * Read into pulling messages from [history](/docs/chat/rooms/history?lang=swift) and providing context to new joiners.
diff --git a/src/pages/docs/chat/getting-started/swift.mdx b/src/pages/docs/chat/getting-started/swift.mdx
index 36b0252268..120e435802 100644
--- a/src/pages/docs/chat/getting-started/swift.mdx
+++ b/src/pages/docs/chat/getting-started/swift.mdx
@@ -62,7 +62,7 @@ Create a new iOS project with SwiftUI. For detailed instructions, refer to the [
 
 Replace the contents of your `ContentView.swift` file with the following code to set up the Ably client, this is using a demo API key, if you wish to use this application with the CLI, change the API key with your own key:
 
-Note that this is for example purposes only. In production, you should use [token authentication](/docs/auth/token) to avoid exposing your API keys publicly, the [`clientId`](/docs/auth/identified-clients) is used to identify the client:
+Note that this is for example purposes only. In production, you should use [token authentication](/docs/platform/auth/token) to avoid exposing your API keys publicly, the [`clientId`](/docs/platform/auth/identified-clients) is used to identify the client:
 
 <Code>
 ```swift
@@ -1292,7 +1292,7 @@ var body: some View {
 
 Continue to explore the documentation with Swift as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Read more about using [rooms](/docs/chat/rooms?lang=swift) and sending [messages](/docs/chat/rooms/messages?lang=swift).
 * Find out more regarding [presence](/docs/chat/rooms/presence?lang=swift).
 * Read into pulling messages from [history](/docs/chat/rooms/history?lang=swift) and providing context to new joiners.
diff --git a/src/pages/docs/chat/index.mdx b/src/pages/docs/chat/index.mdx
index c4b96234fa..3f1bcf1d63 100644
--- a/src/pages/docs/chat/index.mdx
+++ b/src/pages/docs/chat/index.mdx
@@ -81,4 +81,4 @@ Take a look at a [livestream basketball game](https://ably-livestream-chat-demo.
 * Read more about using [rooms](/docs/chat/rooms) and sending [messages](/docs/chat/rooms/messages).
 * Read into pulling messages from [history](/docs/chat/rooms/history) and providing context to new joiners.
 * Learn about how to add [chat moderation](/docs/chat/moderation).
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
diff --git a/src/pages/docs/chat/setup.mdx b/src/pages/docs/chat/setup.mdx
index 7439e34e79..e1c12ec74e 100644
--- a/src/pages/docs/chat/setup.mdx
+++ b/src/pages/docs/chat/setup.mdx
@@ -12,17 +12,17 @@ If you have any feedback or feature requests, [let us know](https://forms.gle/Sm
 ## Authentication <a id="authentication"/>
 
 <Aside data-type='important'>
-Client-side applications must use [JWT authentication](/docs/auth/token/jwt). API keys should never be exposed in client-side code because they don't expire and cannot be scoped to specific users.
+Client-side applications must use [JWT authentication](/docs/platform/auth/token/jwt). API keys should never be exposed in client-side code because they don't expire and cannot be scoped to specific users.
 </Aside>
 
 Chat requires an authenticated client with a `clientId` to identify users. The recommended approach is:
 
-1. **Client-side apps** (browsers, iOS, Android): Use [JWT authentication](/docs/auth/token/jwt) with `authCallback` to fetch JWTs from your server
+1. **Client-side apps** (browsers, iOS, Android): Use [JWT authentication](/docs/platform/auth/token/jwt) with `authCallback` to fetch JWTs from your server
 2. **Server-side apps** (Node.js, Python, etc.): Use your API key directly
 
 [Sign up](https://ably.com/sign-up) to Ably to create an API key in the [dashboard](https://ably.com/dashboard) or use the [Control API](/docs/platform/account/control-api) to create an API key programmatically. Your server will use this key to issue tokens to clients.
 
-API keys and tokens have a set of [capabilities](/docs/auth/capabilities) assigned to them that specify which operations, such as subscribe or publish can be performed on which resources. To use the Chat SDK, the API key requires the following capabilities depending on which features are being used:
+API keys and tokens have a set of [capabilities](/docs/platform/auth/capabilities) assigned to them that specify which operations, such as subscribe or publish can be performed on which resources. To use the Chat SDK, the API key requires the following capabilities depending on which features are being used:
 
 | Feature | Capabilities |
 | ------- | ------------ |
@@ -43,7 +43,7 @@ When setting the capabilities for Chat, you can apply them to specific chat room
 * `dms:*` - all rooms in the `dms:` namespace
 * `*` - all chat rooms
 
-For more guidance, see the [capabilities documentation](/docs/auth/capabilities) and [Chat authentication](/docs/chat/authentication) for room-scoped examples.
+For more guidance, see the [capabilities documentation](/docs/platform/auth/capabilities) and [Chat authentication](/docs/chat/authentication) for room-scoped examples.
 
 ### Client identification <a id="client-identification"/>
 
@@ -57,7 +57,7 @@ If you try to connect without a `clientId`, the connection will fail.
 
 ### User claims <a id="user-claims"/>
 
-User claims enable you to attach server-signed metadata to a user's authentication token that is automatically included on all events they produce in a chat room. This metadata is set server-side via [JWT claims](/docs/auth/token#jwt) and cannot be modified by clients, making it suitable for trusted information such as display names, roles, or custom attributes.
+User claims enable you to attach server-signed metadata to a user's authentication token that is automatically included on all events they produce in a chat room. This metadata is set server-side via [JWT claims](/docs/platform/auth/token#jwt) and cannot be modified by clients, making it suitable for trusted information such as display names, roles, or custom attributes.
 
 User claims are scoped to individual chat rooms using the `ably.room.<roomName>` key in the JWT payload. The value is an arbitrary string, commonly a JSON-encoded object. When a user publishes a message, enters presence, sends a typing indicator, or sends a reaction in a matching room, the claim is automatically copied by Ably servers into the `userClaim` field of the event.
 
@@ -360,7 +360,7 @@ val chatClient = ChatClient(realtimeClient)
 ```
 </Code>
 
-Your auth server endpoint (`/api/ably-token`) should authenticate the user and return a token. See the [token authentication](/docs/auth/token) documentation for server implementation examples.
+Your auth server endpoint (`/api/ably-token`) should authenticate the user and return a token. See the [token authentication](/docs/platform/auth/token) documentation for server implementation examples.
 
 ### Server-side authentication <a id="server-side-auth"/>
 
@@ -384,7 +384,7 @@ const chatClient = new ChatClient(realtimeClient, { logLevel: LogLevel.Error });
 API key authentication should only be used server-side. For client-side apps (React, iOS, Android), always use [token authentication](#client-side-auth) instead.
 </Aside>
 
-A [`ClientOptions`](/docs/api/realtime-sdk#client-options) object may be passed to the Pub/Sub SDK instance to further customize the connection. When using token authentication, the `clientId` is set by your auth server. When using API key authentication server-side, you must provide a `clientId` to ensure that the client is [identified](/docs/auth/identified-clients).
+A [`ClientOptions`](/docs/api/realtime-sdk#client-options) object may be passed to the Pub/Sub SDK instance to further customize the connection. When using token authentication, the `clientId` is set by your auth server. When using API key authentication server-side, you must provide a `clientId` to ensure that the client is [identified](/docs/platform/auth/identified-clients).
 
 ### Using Ably JWT (alternative) <a id="jwt-auth"/>
 
@@ -468,10 +468,10 @@ val chatClient = ChatClient(realtimeClient)
 **Why choose JWT for Chat?**
 - No Ably SDK required on your server
 - Integrates with existing Auth0/Firebase/Cognito flows
-- Supports [channel-scoped claims](/docs/auth/capabilities#custom-restrictions) for user roles in chat rooms
+- Supports [channel-scoped claims](/docs/platform/auth/capabilities#custom-restrictions) for user roles in chat rooms
 - Eliminates client round-trip to Ably
 
-See [Token authentication](/docs/auth/token#choosing) for detailed guidance on when to use JWT vs Ably Tokens.
+See [Token authentication](/docs/platform/auth/token#choosing) for detailed guidance on when to use JWT vs Ably Tokens.
 
 Additional options can also be passed to the Chat client to customize the following properties:
 
diff --git a/src/pages/docs/connect/index.mdx b/src/pages/docs/connect/index.mdx
index 5e677d29ad..a836364d8b 100644
--- a/src/pages/docs/connect/index.mdx
+++ b/src/pages/docs/connect/index.mdx
@@ -137,7 +137,7 @@ Explicitly calling connect is unnecessary unless the ClientOptions attribute aut
 
 Connection monitoring allows you to view and manage the [states of connections](/docs/connect/states) to Ably, showing events for individual people connecting and disconnecting. The developer console in your Ably account also shows these events.
 
-This feature is intended for debugging, so once the number of new connections exceeds the number of messages per second permitted by the lifecycle channel, new events will be dropped. This means if you want a definitive list of everyone using your app you'd be best using [token authentication](/docs/auth/token) to create your own 'auth server'.
+This feature is intended for debugging, so once the number of new connections exceeds the number of messages per second permitted by the lifecycle channel, new events will be dropped. This means if you want a definitive list of everyone using your app you'd be best using [token authentication](/docs/platform/auth/token) to create your own 'auth server'.
 
 The Ably dashboard contains a developer console. In the developer console you can view connection events.
 
diff --git a/src/pages/docs/connect/states.mdx b/src/pages/docs/connect/states.mdx
index 60f98e8638..7d9c78e2f2 100644
--- a/src/pages/docs/connect/states.mdx
+++ b/src/pages/docs/connect/states.mdx
@@ -58,7 +58,7 @@ After a period of being offline a connection is re-established:
 
 The `Connection` object is an `EventEmitter` and emits an event whose name is the new state whenever there is a connection state change. An event listener function is passed a [ConnectionStateChange](/docs/api/realtime-sdk/connection#connection-state-change) object as the first argument for state change events.
 
-The `Connection` object can also emit an event that is not a state change: an `update` event. This happens when there's a change to connection conditions and there is no applicable status or the state doesn't change, such as when an SDK remains connected after a [reauth](/docs/auth).
+The `Connection` object can also emit an event that is not a state change: an `update` event. This happens when there's a change to connection conditions and there is no applicable status or the state doesn't change, such as when an SDK remains connected after a [reauth](/docs/platform/auth).
 
 <Code>
 ```realtime_javascript
diff --git a/src/pages/docs/faq/index.mdx b/src/pages/docs/faq/index.mdx
index 9f62613b27..ef2ff229cd 100644
--- a/src/pages/docs/faq/index.mdx
+++ b/src/pages/docs/faq/index.mdx
@@ -127,9 +127,9 @@ Available timeout options:
 
 ### Can I change my connection's clientId after connecting? <a id="client-id-change"/>
 
-A connection's [`clientId`](/docs/auth/identified-clients) is immutable once set.
+A connection's [`clientId`](/docs/platform/auth/identified-clients) is immutable once set.
 
-However, late initialization of `clientId` is possible. For instance, if the library is instantiated with an [`authCallback`](/docs/auth/token/jwt#auth-callback), the `clientId` may only be known after the callback completes. Similarly, if the library uses an opaque token string, it learns the `clientId` only after the server processes the token. In both cases, the "immutable" requirement is satisfied because the `clientId` is set during the client's first interaction with the server.
+However, late initialization of `clientId` is possible. For instance, if the library is instantiated with an [`authCallback`](/docs/platform/auth/token/jwt#auth-callback), the `clientId` may only be known after the callback completes. Similarly, if the library uses an opaque token string, it learns the `clientId` only after the server processes the token. In both cases, the "immutable" requirement is satisfied because the `clientId` is set during the client's first interaction with the server.
 
 ## Connection and network issues <a id="connection-network"/>
 
diff --git a/src/pages/docs/faq/push-faqs.mdx b/src/pages/docs/faq/push-faqs.mdx
index 849295a034..5e84eeb918 100644
--- a/src/pages/docs/faq/push-faqs.mdx
+++ b/src/pages/docs/faq/push-faqs.mdx
@@ -69,7 +69,7 @@ Follow these steps to check if your device is correctly registered with Ably:
 
 | Step | Description | Action/State |
 |------|-------------|--------------|
-| Check registration | Go to Ably dashboard > Notifications > Device inspector. Search using `deviceId` or [`clientId`](/docs/auth/identified-clients). | - |
+| Check registration | Go to Ably dashboard > Notifications > Device inspector. Search using `deviceId` or [`clientId`](/docs/platform/auth/identified-clients). | - |
 | Device states | Registered and should receive notifications. Test using the push inspector in the Notifications tab or test using the `REST` `API` to publish directly to the `deviceId`. | **ACTIVE** |
 | Device states | Indicates an error "registration expired" if the app was uninstalled. | **FAILED** |
 | No registration Found | Enable verbose logs and retry the push registration process to view Ably push `API` requests. | - |
@@ -104,15 +104,15 @@ If there are no errors, the notification was successfully sent to the push provi
 
 ### Why are my push notifications duplicated? <a id="duplicated-notifications"/>
 
-Consistent duplication on a specific device usually indicates both a `deviceId` and a [`clientId`](/docs/auth/identified-clients) subscription to the push [channel](/docs/channels). Remove one to prevent duplication.
+Consistent duplication on a specific device usually indicates both a `deviceId` and a [`clientId`](/docs/platform/auth/identified-clients) subscription to the push [channel](/docs/channels). Remove one to prevent duplication.
 
 - DeviceId subscriptions: Deliver to a single device.
-- [ClientId subscriptions](/docs/auth/identified-clients): Deliver to all devices identified by that `clientId`.
+- [ClientId subscriptions](/docs/platform/auth/identified-clients): Deliver to all devices identified by that `clientId`.
 
 ### Why can I not publish push notifications on channels? <a id="cannot-publish-push"/>
 
 If you're unable to [publish](/docs/channels#publish) push notifications to [channels](/docs/channels), this is typically due to configuration or permission issues. The following are possible reasons for this issue:
 
 1. [Channel Rules](/docs/channels#rules): Channels must be explicitly enabled for push notifications via channel rules. They are disabled by default.
-2. [Permissions](/docs/auth/capabilities): The publisher must have permission to publish to that channel.
+2. [Permissions](/docs/platform/auth/capabilities): The publisher must have permission to publish to that channel.
 3. Invalid Payload: If the push notification payload in the `extras` field is invalid, the message may be rejected immediately.
diff --git a/src/pages/docs/getting-started/dotnet.mdx b/src/pages/docs/getting-started/dotnet.mdx
index c235dd4ec1..26c5d528a0 100644
--- a/src/pages/docs/getting-started/dotnet.mdx
+++ b/src/pages/docs/getting-started/dotnet.mdx
@@ -14,7 +14,7 @@ You'll establish a realtime connection to Ably and learn to publish and subscrib
 
 1. [Sign up](https://ably.com/sign-up) for an Ably account.
 2. Create a [new app](https://ably.com/accounts/any/apps/new), and create your first API key in the **API Keys** tab of the dashboard.
-3. Your API key will need the `publish`, `subscribe`, `presence` and `history` [capabilities](/docs/auth/capabilities).
+3. Your API key will need the `publish`, `subscribe`, `presence` and `history` [capabilities](/docs/platform/auth/capabilities).
 4. Install [.NET SDK](https://dotnet.microsoft.com/download) (version 6.0 or later).
 5. Create a new C# console application:
 
@@ -65,7 +65,7 @@ Clients establish a connection with Ably when they instantiate an SDK instance.
 
 Open up the [dev console](https://ably.com/accounts/any/apps/any/console) of your first app before instantiating your client so that you can see what happens.
 
-Replace the contents of your `Program.cs` file with functionality to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/auth/token) in production environments. A [`clientId`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
+Replace the contents of your `Program.cs` file with functionality to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/platform/auth/token) in production environments. A [`clientId`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
 
 <Code>
 ```csharp
@@ -232,7 +232,7 @@ The output will look similar to the following:
 
 Continue to explore the documentation with C# .NET as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=csharp).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=csharp) Pub/Sub concepts.
 
diff --git a/src/pages/docs/getting-started/flutter.mdx b/src/pages/docs/getting-started/flutter.mdx
index c3c4a5ccf3..2df94aa8ed 100644
--- a/src/pages/docs/getting-started/flutter.mdx
+++ b/src/pages/docs/getting-started/flutter.mdx
@@ -16,7 +16,7 @@ You'll establish a realtime connection to Ably and learn to publish and subscrib
 
 1. [Sign up](https://ably.com/sign-up) for a free Ably account.
 2. Create a [new app](https://ably.com/accounts/any/apps/new), and create your first API key in the **API Keys** tab of the dashboard.
-3. Your API key will need the `publish`, `subscribe`, `presence` and `history` [capabilities](/docs/auth/capabilities).
+3. Your API key will need the `publish`, `subscribe`, `presence` and `history` [capabilities](/docs/platform/auth/capabilities).
 
 ### Create a Flutter project <a id="prerequisites-create-project"/>
 
@@ -189,7 +189,7 @@ ably login
 
 Clients establish a connection with Ably when they instantiate an SDK instance. This enables them to send and receive messages in realtime across channels.
 
-In the [Set up Ably Realtime Client](#prerequisites-setup-ably-client) section, you added code to create an Ably Realtime client. This code creates a new Realtime client instance, establishing a connection to Ably when your application starts. At the minimum you need to provide an authentication mechanism. While using an API key is fine for the purposes of this guide, you should use [token authentication](/docs/auth/token) in production environments. A [`clientId`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence.
+In the [Set up Ably Realtime Client](#prerequisites-setup-ably-client) section, you added code to create an Ably Realtime client. This code creates a new Realtime client instance, establishing a connection to Ably when your application starts. At the minimum you need to provide an authentication mechanism. While using an API key is fine for the purposes of this guide, you should use [token authentication](/docs/platform/auth/token) in production environments. A [`clientId`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence.
 
 To monitor the Ably connection state within your application, create a widget that displays the current connection state. Create a new file `lib/widgets/connection_state.dart`:
 
@@ -728,7 +728,7 @@ Message number 5
 
 Continue to explore the documentation with Flutter as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=flutter).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=flutter) Pub/Sub concepts.
 
diff --git a/src/pages/docs/getting-started/go.mdx b/src/pages/docs/getting-started/go.mdx
index 092eeb208d..6cd4bdb2bf 100644
--- a/src/pages/docs/getting-started/go.mdx
+++ b/src/pages/docs/getting-started/go.mdx
@@ -56,7 +56,7 @@ ably login
 
 Clients establish a connection with Ably when they instantiate an SDK instance. This enables them to send and receive messages in realtime across channels.
 
-Create a `main.go` file in your project and add the following function to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/auth/token) in production environments. A [`clientId`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
+Create a `main.go` file in your project and add the following function to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/platform/auth/token) in production environments. A [`clientId`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
 
 <Code>
 ```go
@@ -243,7 +243,7 @@ The output will look similar to the following:
 
 Continue to explore the documentation with Go as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=go).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=go) Pub/Sub concepts.
 
diff --git a/src/pages/docs/getting-started/java.mdx b/src/pages/docs/getting-started/java.mdx
index c5cc497dff..974140a9e6 100644
--- a/src/pages/docs/getting-started/java.mdx
+++ b/src/pages/docs/getting-started/java.mdx
@@ -14,7 +14,7 @@ You'll establish a realtime connection to Ably and learn to publish and subscrib
 
 1. [Sign up](https://ably.com/sign-up) for an Ably account.
 2. Create a [new app](https://ably.com/accounts/any/apps/new), and create your first API key in the **API Keys** tab of the dashboard.
-3. Your API key will need the `publish`, `subscribe`, `presence` and `history` [capabilities](/docs/auth/capabilities).
+3. Your API key will need the `publish`, `subscribe`, `presence` and `history` [capabilities](/docs/platform/auth/capabilities).
 4. Install [Java Development Kit (JDK)](https://adoptium.net/) version 8 or greater.
 5. Create a new project and add the Ably [Pub/Sub Java SDK](https://github.com/ably/ably-java) as a dependency.
 
@@ -76,7 +76,7 @@ Clients establish a connection with Ably when they instantiate an SDK instance.
 
 Open up the [dev console](https://ably.com/accounts/any/apps/any/console) of your first app before instantiating your client so that you can see what happens.
 
-Replace the contents of your `App.java` file with functionality to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/auth/token) in production environments. A [`clientId`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
+Replace the contents of your `App.java` file with functionality to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/platform/auth/token) in production environments. A [`clientId`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
 
 <Code>
 ```java
@@ -239,7 +239,7 @@ The output will look similar to the following:
 
 Continue to explore the documentation with Java as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=java).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=java) Pub/Sub concepts.
 
diff --git a/src/pages/docs/getting-started/javascript.mdx b/src/pages/docs/getting-started/javascript.mdx
index 0300e7e89c..7356c08268 100644
--- a/src/pages/docs/getting-started/javascript.mdx
+++ b/src/pages/docs/getting-started/javascript.mdx
@@ -50,7 +50,7 @@ Clients establish a connection with Ably when they instantiate an SDK instance.
 
 Open up the [dev console](https://ably.com/accounts/any/apps/any/console) of your first app before instantiating your client so that you can see what happens.
 
-Create an `index.html` file in your project and add the following HTML to include the Ably JavaScript SDK via CDN and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [JWT authentication](/docs/auth/token/jwt) in a production app. A [`clientId`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
+Create an `index.html` file in your project and add the following HTML to include the Ably JavaScript SDK via CDN and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [JWT authentication](/docs/platform/auth/token/jwt) in a production app. A [`clientId`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
 
 <Code>
 ```html
@@ -206,7 +206,7 @@ The output will look similar to the following:
 
 Continue to explore the documentation with JavaScript as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=javascript).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=javascript) Pub/Sub concepts.
 
diff --git a/src/pages/docs/getting-started/kotlin.mdx b/src/pages/docs/getting-started/kotlin.mdx
index d9e5df9b0a..3fd9055218 100644
--- a/src/pages/docs/getting-started/kotlin.mdx
+++ b/src/pages/docs/getting-started/kotlin.mdx
@@ -55,7 +55,7 @@ Clients establish a connection with Ably when they instantiate an SDK. This enab
 
 Open up the [dev console](https://ably.com/accounts/any/apps/any/console) of your first app before instantiating your client so that you can see what happens.
 
-Create a `Main.kt` file in your project and add the following function to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/auth/token) in production environments. A [`clientId`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
+Create a `Main.kt` file in your project and add the following function to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/platform/auth/token) in production environments. A [`clientId`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
 
 <Code>
 ```kotlin
@@ -184,7 +184,7 @@ The output will look similar to the following:
 
 Continue to explore the documentation with Kotlin as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=kotlin).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=kotlin) Pub/Sub concepts.
 
diff --git a/src/pages/docs/getting-started/node.mdx b/src/pages/docs/getting-started/node.mdx
index 2bc3d5a7e7..87be68c30f 100644
--- a/src/pages/docs/getting-started/node.mdx
+++ b/src/pages/docs/getting-started/node.mdx
@@ -68,7 +68,7 @@ Clients establish a connection with Ably when they instantiate an SDK instance.
 
 Open up the [dev console](https://ably.com/accounts/any/apps/any/console) of your first app before instantiating your client so that you can see what happens.
 
-Create an `index.js` file in your project and add the following function to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [JWT authentication](/docs/auth/token/jwt) in a production app. A [`clientId`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
+Create an `index.js` file in your project and add the following function to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [JWT authentication](/docs/platform/auth/token/jwt) in a production app. A [`clientId`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
 
 <Code>
 ```nodejs
@@ -199,7 +199,7 @@ The output will look similar to the following:
 
 Continue to explore the documentation with JavaScript as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=nodejs).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=nodejs) Pub/Sub concepts.
 
diff --git a/src/pages/docs/getting-started/objective-c.mdx b/src/pages/docs/getting-started/objective-c.mdx
index d1d3f41d19..26b47dc965 100644
--- a/src/pages/docs/getting-started/objective-c.mdx
+++ b/src/pages/docs/getting-started/objective-c.mdx
@@ -18,7 +18,7 @@ You'll establish a realtime connection to Ably and learn to publish and subscrib
 
 1. [Sign up](https://ably.com/sign-up) for an Ably account.
 2. Create a [new app](https://ably.com/accounts/any/apps/new), and create your first API key in the **API Keys** tab of the dashboard.
-3. Your API key will need the `publish`, `subscribe`, `presence` and `history` [capabilities](/docs/auth/capabilities).
+3. Your API key will need the `publish`, `subscribe`, `presence` and `history` [capabilities](/docs/platform/auth/capabilities).
 4. Install Xcode and create a new Objective-C project.
 5. Add the Ably [Pub/Sub Objective-C SDK](https://github.com/ably/ably-cocoa) as a dependency.
 
@@ -70,7 +70,7 @@ Clients establish a connection with Ably when they instantiate an SDK instance.
 
 Open up the [dev console](https://ably.com/accounts/any/apps/any/console) of your first app before instantiating your client so that you can see what happens.
 
-Replace the contents of your `main.m` file with functionality to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/auth/token) in production environments. A [`clientId`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
+Replace the contents of your `main.m` file with functionality to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/platform/auth/token) in production environments. A [`clientId`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
 
 <Code>
 ```objc
@@ -227,7 +227,7 @@ The output will look similar to the following:
 
 Continue to explore the documentation with Objective-C as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=objc).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=objc) Pub/Sub concepts.
 
diff --git a/src/pages/docs/getting-started/php.mdx b/src/pages/docs/getting-started/php.mdx
index dc8b0d900a..58718a6abc 100644
--- a/src/pages/docs/getting-started/php.mdx
+++ b/src/pages/docs/getting-started/php.mdx
@@ -66,7 +66,7 @@ ably login
 
 Clients can make REST API requests to Ably when they instantiate a REST SDK instance. This enables them to publish messages to channels and retrieve channel information.
 
-Create a `get_started.php` file in your project and add the following code to instantiate the SDK and make requests to Ably. At the minimum you need to provide an authentication mechanism. Using an API key directly is fine for server-side environments like PHP where the key remains secure. However, for frontend clients, you should use [token authentication](/docs/auth/token) instead of exposing API keys. In this example, the [`clientId`](/docs/auth/identified-clients) will be the name of the client sending the message:
+Create a `get_started.php` file in your project and add the following code to instantiate the SDK and make requests to Ably. At the minimum you need to provide an authentication mechanism. Using an API key directly is fine for server-side environments like PHP where the key remains secure. However, for frontend clients, you should use [token authentication](/docs/platform/auth/token) instead of exposing API keys. In this example, the [`clientId`](/docs/platform/auth/identified-clients) will be the name of the client sending the message:
 
 <Code>
 ```php
@@ -230,7 +230,7 @@ The output will look similar to the following:
 
 Continue to explore the documentation with PHP as the selected language:
 
-* Dive into [authenticating](/docs/auth/token/jwt?lang=php) your frontend applications with your PHP backend.
+* Dive into [authenticating](/docs/platform/auth/token/jwt?lang=php) your frontend applications with your PHP backend.
 * Explore more [advanced](/docs/pub-sub/advanced?lang=php) Pub/Sub concepts.
 
 You can also explore the [Ably CLI](https://www.npmjs.com/package/@ably/cli) further, or visit the Pub/Sub [API references](/docs/api/rest-sdk?lang=php).
diff --git a/src/pages/docs/getting-started/python.mdx b/src/pages/docs/getting-started/python.mdx
index 85e63129eb..0927cecd99 100644
--- a/src/pages/docs/getting-started/python.mdx
+++ b/src/pages/docs/getting-started/python.mdx
@@ -63,7 +63,7 @@ ably login
 
 Clients establish a connection with Ably when they instantiate an SDK instance. This enables them to send and receive messages in realtime across channels.
 
-Create a `get_started.py` file in your project and add the following function to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/auth/token) in production environments. A [`client_id`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
+Create a `get_started.py` file in your project and add the following function to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/platform/auth/token) in production environments. A [`client_id`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
 
 <Code>
 ```python
@@ -198,7 +198,7 @@ The output will look similar to the following:
 
 Continue to explore the documentation with Python as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=python).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=python) Pub/Sub concepts.
 
diff --git a/src/pages/docs/getting-started/react-hooks.mdx b/src/pages/docs/getting-started/react-hooks.mdx
index e748fa91e9..e47bbb9118 100644
--- a/src/pages/docs/getting-started/react-hooks.mdx
+++ b/src/pages/docs/getting-started/react-hooks.mdx
@@ -40,12 +40,12 @@ React version 16.8 or above is required.
 
 ## Authenticate <a id="authenticate"/>
 
-An [API key](/docs/auth#api-keys) is required to authenticate with Ably. API keys are used either to authenticate directly with Ably using [basic authentication](/docs/auth/basic), or to generate tokens for untrusted clients using [token authentication](/docs/auth/token).
+An [API key](/docs/platform/auth#api-keys) is required to authenticate with Ably. API keys are used either to authenticate directly with Ably using [basic authentication](/docs/platform/auth/basic), or to generate tokens for untrusted clients using [token authentication](/docs/platform/auth/token).
 
 [Sign up](https://ably.com/sign-up) to Ably to create an API key in the [dashboard](https://ably.com/dashboard) or use the [Control API](/docs/platform/account/control-api) to create an API programmatically.
 
 <Aside data-type='important'>
-The examples use [basic authentication](/docs/auth/basic) to demonstrate usage for convenience. In your own applications, basic authentication should never be used on the client-side as it exposes your Ably API key. Instead use [token authentication.](/docs/auth/token)
+The examples use [basic authentication](/docs/platform/auth/basic) to demonstrate usage for convenience. In your own applications, basic authentication should never be used on the client-side as it exposes your Ably API key. Instead use [token authentication.](/docs/platform/auth/token)
 </Aside>
 
 ## Usage <a id="usage"/>
diff --git a/src/pages/docs/getting-started/react-native.mdx b/src/pages/docs/getting-started/react-native.mdx
index bc49ab67c2..cebde25cb9 100644
--- a/src/pages/docs/getting-started/react-native.mdx
+++ b/src/pages/docs/getting-started/react-native.mdx
@@ -16,7 +16,7 @@ You'll establish a realtime connection to Ably and learn to publish and subscrib
 
 1. [Sign up](https://ably.com/sign-up) for a free Ably account.
 2. Create a [new app](https://ably.com/accounts/any/apps/new), and create your first API key in the **API Keys** tab of the dashboard.
-3. Your API key will need the `publish`, `subscribe`, `presence` and `history` [capabilities](/docs/auth/capabilities).
+3. Your API key will need the `publish`, `subscribe`, `presence` and `history` [capabilities](/docs/platform/auth/capabilities).
 
 ### Create a React Native project <a id="prerequisites-create-project"/>
 
@@ -182,7 +182,7 @@ const realtimeClient = new Ably.Realtime({
 ```
 </Code>
 
-This code creates a new Realtime client instance, establishing a connection to Ably when your application starts. At the minimum you need to provide an authentication mechanism. While using an API key is fine for the purposes of this guide, you should use [token authentication](/docs/auth/token) in production environments. A [`clientId`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence.
+This code creates a new Realtime client instance, establishing a connection to Ably when your application starts. At the minimum you need to provide an authentication mechanism. While using an API key is fine for the purposes of this guide, you should use [token authentication](/docs/platform/auth/token) in production environments. A [`clientId`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence.
 
 To monitor the Ably connection state within your application, create a component that uses the `useConnectionStateListener()` hook provided by the Ably Pub/Sub SDK. This hook must be nested inside an `AblyProvider`, so the component must be placed within the `AblyProvider` in your application.
 
@@ -682,7 +682,7 @@ Message number 5
 
 Continue to explore the documentation with React as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=react).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=react) Pub/Sub concepts.
 
diff --git a/src/pages/docs/getting-started/react.mdx b/src/pages/docs/getting-started/react.mdx
index 5b465a54be..49865c0762 100644
--- a/src/pages/docs/getting-started/react.mdx
+++ b/src/pages/docs/getting-started/react.mdx
@@ -188,7 +188,7 @@ const realtimeClient = new Ably.Realtime({
 ```
 </Code>
 
-This code creates a new Realtime client instance, establishing a connection to Ably when your application starts. At the minimum you need to provide an authentication mechanism. While using an API key is fine for the purposes of this guide, you should use [token authentication](/docs/auth/token) in production environments. A [`clientId`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence.
+This code creates a new Realtime client instance, establishing a connection to Ably when your application starts. At the minimum you need to provide an authentication mechanism. While using an API key is fine for the purposes of this guide, you should use [token authentication](/docs/platform/auth/token) in production environments. A [`clientId`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence.
 
 To monitor the Ably connection state within your application, create a component that uses the `useConnectionStateListener()` hook provided by the Ably Pub/Sub SDK. This hook must be nested inside an `AblyProvider`, so the component must be placed within the `AblyProvider` in your application.
 
@@ -627,7 +627,7 @@ Message number 5
 
 Continue to explore the documentation with React as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=react).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=react) Pub/Sub concepts.
 
diff --git a/src/pages/docs/getting-started/ruby.mdx b/src/pages/docs/getting-started/ruby.mdx
index 608c0a72b4..7dc20dcdce 100644
--- a/src/pages/docs/getting-started/ruby.mdx
+++ b/src/pages/docs/getting-started/ruby.mdx
@@ -14,7 +14,7 @@ You'll establish a realtime connection to Ably and learn to publish and subscrib
 
 1. [Sign up](https://ably.com/sign-up) for an Ably account.
 2. Create a [new app](https://ably.com/accounts/any/apps/new), and create your first API key in the **API Keys** tab of the dashboard.
-3. Your API key will need the `publish`, `subscribe`, `presence` and `history` [capabilities](/docs/auth/capabilities).
+3. Your API key will need the `publish`, `subscribe`, `presence` and `history` [capabilities](/docs/platform/auth/capabilities).
 4. Install [Ruby](https://www.ruby-lang.org/en/documentation/installation/) version 2.7 or greater.
 5. Create a new project and install the Ably [Pub/Sub Ruby SDK](https://github.com/ably/ably-ruby):
 
@@ -63,7 +63,7 @@ Clients establish a connection with Ably when they instantiate an SDK instance.
 
 Open up the [dev console](https://ably.com/accounts/any/apps/any/console) of your first app before instantiating your client so that you can see what happens.
 
-Create a `get_started.rb` file in your project and add the following function to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/auth/token) in production environments. A [`client_id`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
+Create a `get_started.rb` file in your project and add the following function to instantiate the SDK and establish a connection to Ably. At the minimum you need to provide an authentication mechanism. Use an API key for simplicity, but you should use [token authentication](/docs/platform/auth/token) in production environments. A [`client_id`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence:
 
 <Code>
 ```ruby
@@ -201,7 +201,7 @@ The output will look similar to the following:
 
 Continue to explore the documentation with Ruby as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=ruby).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=ruby) Pub/Sub concepts.
 
diff --git a/src/pages/docs/getting-started/swift.mdx b/src/pages/docs/getting-started/swift.mdx
index 2b33c2d6e3..2cb10e52f1 100644
--- a/src/pages/docs/getting-started/swift.mdx
+++ b/src/pages/docs/getting-started/swift.mdx
@@ -69,7 +69,7 @@ import Ably
 ```
 </Code>
 
-Create an instance of `ARTRealtime` with your API key and provide a `clientId`. While using an API key is fine for the purposes of this guide, you should use [token authentication](/docs/auth/token) in production environments. A [`clientId`](/docs/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence.
+Create an instance of `ARTRealtime` with your API key and provide a `clientId`. While using an API key is fine for the purposes of this guide, you should use [token authentication](/docs/platform/auth/token) in production environments. A [`clientId`](/docs/platform/auth/identified-clients) ensures the client is identified, which is required to use certain features, such as presence.
 
 This `ARTRealtime` instance is the main entry point for the realtime library. The `ARTRealtime` client connects to Ably as soon as it's instantiated, using a basic transport such as a raw TCP socket or a WebSocket:
 
@@ -246,7 +246,7 @@ The output will look similar to the following:
 
 Continue to explore the documentation with Swift as the selected language:
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Understand how to effectively [manage connections](https://ably.com/docs/connect#close?lang=ruby).
 * Explore more [advanced](/docs/pub-sub/advanced?lang=ruby) Pub/Sub concepts.
 
diff --git a/src/pages/docs/guides/chat/build-livestream.mdx b/src/pages/docs/guides/chat/build-livestream.mdx
index 497795d7ac..05f3c1fb7d 100644
--- a/src/pages/docs/guides/chat/build-livestream.mdx
+++ b/src/pages/docs/guides/chat/build-livestream.mdx
@@ -377,5 +377,5 @@ Before you go live, review these key points:
 * Try out the [livestream chat demo](https://ably-livestream-chat-demo.vercel.app).
 * Read the [JavaScript / TypeScript](/docs/chat/getting-started/javascript) or [React](/docs/chat/getting-started/react) getting started guides.
 * Learn about how to add [chat moderation](/docs/chat/moderation).
-* Understand [JWT authentication](/docs/auth/token/jwt) before going to production.
+* Understand [JWT authentication](/docs/platform/auth/token/jwt) before going to production.
 * Learn how to set up [server-side batching](/docs/messages/batch#server-side).
diff --git a/src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx b/src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx
index 9edbdcac9f..9663687e45 100644
--- a/src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx
+++ b/src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx
@@ -122,7 +122,7 @@ assignedPatients.forEach(patientId => {
 ```
 </Code>
 
-Per-entity channels enable you to apply different [capabilities](/docs/auth/capabilities) to each channel, ensuring that users can only subscribe to the data they're authorized to see. This pattern also provides natural isolation where a spike in activity on one channel doesn't affect others, and you can apply different [rules](/docs/channels#rules), such as server-side batching or conflation, to different channel namespaces.
+Per-entity channels enable you to apply different [capabilities](/docs/platform/auth/capabilities) to each channel, ensuring that users can only subscribe to the data they're authorized to see. This pattern also provides natural isolation where a spike in activity on one channel doesn't affect others, and you can apply different [rules](/docs/channels#rules), such as server-side batching or conflation, to different channel namespaces.
 
 ### Hierarchical channels for drill-down dashboards
 
@@ -781,7 +781,7 @@ Before deploying your realtime dashboard to production, verify that you've addre
 ## Next steps
 
 * Explore the [Ably Pub/Sub documentation](/docs/pub-sub) for API details.
-* Review [authentication best practices](/docs/auth/token) before going to production.
+* Review [authentication best practices](/docs/platform/auth/token) before going to production.
 * Learn about [connection state recovery](/docs/connect/states#connection-state-recovery) for reliable reconnection.
 * Configure [outbound streaming](/docs/platform/integrations/streaming) for analytics and long-term storage.
 * Set up [webhooks](/docs/platform/integrations/webhooks) for event-driven integrations.
diff --git a/src/pages/docs/liveobjects/concepts/operations.mdx b/src/pages/docs/liveobjects/concepts/operations.mdx
index 3353bfa619..4ab6e91425 100644
--- a/src/pages/docs/liveobjects/concepts/operations.mdx
+++ b/src/pages/docs/liveobjects/concepts/operations.mdx
@@ -307,7 +307,7 @@ The following are the properties of an `ObjectMessage`:
 | Property | Description |
 |----------|-------------|
 | **id** | Unique ID assigned by Ably to this object message |
-| **clientId** | The [ID of the client](/docs/auth/identified-clients) that published this operation |
+| **clientId** | The [ID of the client](/docs/platform/auth/identified-clients) that published this operation |
 | **connectionId** | The ID of the connection used to publish this operation |
 | **timestamp** | The timestamp of when the object message was received by Ably, as milliseconds since the Unix epoch |
 | **channel** | The name of the channel the object message was published to |
diff --git a/src/pages/docs/liveobjects/inband-objects.mdx b/src/pages/docs/liveobjects/inband-objects.mdx
index ca30536478..d5416e880e 100644
--- a/src/pages/docs/liveobjects/inband-objects.mdx
+++ b/src/pages/docs/liveobjects/inband-objects.mdx
@@ -53,7 +53,7 @@ await channel.setOptions({ params: { objects: 'objects' } });
 </Code>
 
 <Aside data-type='important'>
-Clients require the `channel-metadata` [capability](/docs/auth/capabilities) to receive inband objects updates.
+Clients require the `channel-metadata` [capability](/docs/platform/auth/capabilities) to receive inband objects updates.
 </Aside>
 
 ## Subscribe to updates <a id="inband-objects-subscribe"/>
diff --git a/src/pages/docs/liveobjects/quickstart/java.mdx b/src/pages/docs/liveobjects/quickstart/java.mdx
index 3594c5336a..9c004c0216 100644
--- a/src/pages/docs/liveobjects/quickstart/java.mdx
+++ b/src/pages/docs/liveobjects/quickstart/java.mdx
@@ -20,22 +20,22 @@ You will learn how to:
 
 ## Authentication <a id="step-0"/>
 
-An [API key](/docs/auth#api-keys) is required to authenticate with Ably. API keys are used either to authenticate directly with Ably using [basic authentication](/docs/auth/basic), or to generate tokens for untrusted clients using [token authentication](/docs/auth/token).
+An [API key](/docs/platform/auth#api-keys) is required to authenticate with Ably. API keys are used either to authenticate directly with Ably using [basic authentication](/docs/platform/auth/basic), or to generate tokens for untrusted clients using [token authentication](/docs/platform/auth/token).
 
 <Aside data-type='important'>
-The examples use [basic authentication](/docs/auth/basic) to demonstrate features for convenience. In your own applications, basic authentication should never be used on the client-side as it exposes your Ably API key. Instead use [token authentication](/docs/auth/token).
+The examples use [basic authentication](/docs/platform/auth/basic) to demonstrate features for convenience. In your own applications, basic authentication should never be used on the client-side as it exposes your Ably API key. Instead use [token authentication](/docs/platform/auth/token).
 </Aside>
 
 [Sign up](https://ably.com/sign-up) for a free account and create your own API key in the [dashboard](https://ably.com/dashboard) or use the [Control API](/docs/platform/account/control-api) to create an API key programmatically.
 
-API keys and tokens have a set of [capabilities](/docs/auth/capabilities) assigned to them that specify which operations can be performed on which resources. The following capabilities are available for LiveObjects:
+API keys and tokens have a set of [capabilities](/docs/platform/auth/capabilities) assigned to them that specify which operations can be performed on which resources. The following capabilities are available for LiveObjects:
 
 * `object-subscribe` - grants clients read access to LiveObjects, allowing them to get the root object and subscribe to updates.
 * `object-publish` - grants clients write access to LiveObjects, allowing them to perform mutation operations on objects.
 
 To use LiveObjects, an API key must have at least the `object-subscribe` capability. With only this capability, clients will have read-only access, preventing them from calling mutation methods on LiveObjects.
 
-For the purposes of this guide, make sure your API key includes both `object-subscribe` and `object-publish` [capabilities](/docs/auth/capabilities) to allow full read and write access.
+For the purposes of this guide, make sure your API key includes both `object-subscribe` and `object-publish` [capabilities](/docs/platform/auth/capabilities) to allow full read and write access.
 
 ## Install Ably Pub/Sub SDK <a id="step-1"/>
 
diff --git a/src/pages/docs/liveobjects/quickstart/javascript.mdx b/src/pages/docs/liveobjects/quickstart/javascript.mdx
index 3ee1d2ffc3..0f8c771ab8 100644
--- a/src/pages/docs/liveobjects/quickstart/javascript.mdx
+++ b/src/pages/docs/liveobjects/quickstart/javascript.mdx
@@ -23,22 +23,22 @@ You will learn how to:
 
 ## Authentication <a id="step-0"/>
 
-An [API key](/docs/auth#api-keys) is required to authenticate with Ably. API keys are used either to authenticate directly with Ably using [basic authentication](/docs/auth/basic), or to generate tokens for untrusted clients using [token authentication](/docs/auth/token).
+An [API key](/docs/platform/auth#api-keys) is required to authenticate with Ably. API keys are used either to authenticate directly with Ably using [basic authentication](/docs/platform/auth/basic), or to generate tokens for untrusted clients using [token authentication](/docs/platform/auth/token).
 
 <Aside data-type='important'>
-The examples use [basic authentication](/docs/auth/basic) to demonstrate features for convenience. In your own applications, basic authentication should never be used on the client-side as it exposes your Ably API key. Instead use [token authentication](/docs/auth/token).
+The examples use [basic authentication](/docs/platform/auth/basic) to demonstrate features for convenience. In your own applications, basic authentication should never be used on the client-side as it exposes your Ably API key. Instead use [token authentication](/docs/platform/auth/token).
 </Aside>
 
 [Sign up](https://ably.com/sign-up) for a free account and create your own API key in the [dashboard](https://ably.com/dashboard) or use the [Control API](/docs/platform/account/control-api) to create an API key programmatically.
 
-API keys and tokens have a set of [capabilities](/docs/auth/capabilities) assigned to them that specify which operations can be performed on which resources. The following capabilities are available for LiveObjects:
+API keys and tokens have a set of [capabilities](/docs/platform/auth/capabilities) assigned to them that specify which operations can be performed on which resources. The following capabilities are available for LiveObjects:
 
 * `object-subscribe` - grants clients read access to LiveObjects, allowing them to get the channel object and subscribe to updates.
 * `object-publish` - grants clients write access to LiveObjects, allowing them to perform mutation operations on objects.
 
 To use LiveObjects, an API key must have at least the `object-subscribe` capability. With only this capability, clients will have read-only access, preventing them from calling mutation methods on LiveObjects.
 
-For the purposes of this guide, make sure your API key includes both `object-subscribe` and `object-publish` [capabilities](/docs/auth/capabilities) to allow full read and write access.
+For the purposes of this guide, make sure your API key includes both `object-subscribe` and `object-publish` [capabilities](/docs/platform/auth/capabilities) to allow full read and write access.
 
 ## Install Ably Pub/Sub SDK <a id="step-1"/>
 
diff --git a/src/pages/docs/liveobjects/quickstart/swift.mdx b/src/pages/docs/liveobjects/quickstart/swift.mdx
index bfc09fbf15..ab22482e41 100644
--- a/src/pages/docs/liveobjects/quickstart/swift.mdx
+++ b/src/pages/docs/liveobjects/quickstart/swift.mdx
@@ -20,22 +20,22 @@ You will learn how to:
 
 ## Authentication <a id="step-0"/>
 
-An [API key](/docs/auth#api-keys) is required to authenticate with Ably. API keys are used either to authenticate directly with Ably using [basic authentication](/docs/auth/basic), or to generate tokens for untrusted clients using [token authentication](/docs/auth/token).
+An [API key](/docs/platform/auth#api-keys) is required to authenticate with Ably. API keys are used either to authenticate directly with Ably using [basic authentication](/docs/platform/auth/basic), or to generate tokens for untrusted clients using [token authentication](/docs/platform/auth/token).
 
 <Aside data-type='important'>
-The examples use [basic authentication](/docs/auth/basic) to demonstrate features for convenience. In your own applications, basic authentication should never be used on the client-side as it exposes your Ably API key. Instead use [token authentication](/docs/auth/token).
+The examples use [basic authentication](/docs/platform/auth/basic) to demonstrate features for convenience. In your own applications, basic authentication should never be used on the client-side as it exposes your Ably API key. Instead use [token authentication](/docs/platform/auth/token).
 </Aside>
 
 [Sign up](https://ably.com/sign-up) for a free account and create your own API key in the [dashboard](https://ably.com/dashboard) or use the [Control API](/docs/platform/account/control-api) to create an API key programmatically.
 
-API keys and tokens have a set of [capabilities](/docs/auth/capabilities) assigned to them that specify which operations can be performed on which resources. The following capabilities are available for LiveObjects:
+API keys and tokens have a set of [capabilities](/docs/platform/auth/capabilities) assigned to them that specify which operations can be performed on which resources. The following capabilities are available for LiveObjects:
 
 * `object-subscribe` - grants clients read access to LiveObjects, allowing them to get the root object and subscribe to updates.
 * `object-publish` - grants clients write access to LiveObjects, allowing them to perform mutation operations on objects.
 
 To use LiveObjects, an API key must have at least the `object-subscribe` capability. With only this capability, clients will have read-only access, preventing them from calling mutation methods on LiveObjects.
 
-For the purposes of this guide, make sure your API key includes both `object-subscribe` and `object-publish` [capabilities](/docs/auth/capabilities) to allow full read and write access.
+For the purposes of this guide, make sure your API key includes both `object-subscribe` and `object-publish` [capabilities](/docs/platform/auth/capabilities) to allow full read and write access.
 
 ## Install Ably Pub/Sub SDK <a id="step-1"/>
 
diff --git a/src/pages/docs/liveobjects/rest-api-usage.mdx b/src/pages/docs/liveobjects/rest-api-usage.mdx
index 6a7c997148..0721bf99e2 100644
--- a/src/pages/docs/liveobjects/rest-api-usage.mdx
+++ b/src/pages/docs/liveobjects/rest-api-usage.mdx
@@ -17,7 +17,7 @@ View the REST API [authentication](/docs/api/liveobjects-rest#authentication) do
 
 To use LiveObjects, an API key must have at least the `object-subscribe` capability. With only this capability, clients will have read-only access, preventing them from publishing operations.
 
-In order to create or update objects, make sure your API key includes both `object-subscribe` and `object-publish` [capabilities](/docs/auth/capabilities) to allow full read and write access.
+In order to create or update objects, make sure your API key includes both `object-subscribe` and `object-publish` [capabilities](/docs/platform/auth/capabilities) to allow full read and write access.
 
 ## Fetching objects <a id="fetching-objects"/>
 
diff --git a/src/pages/docs/livesync/index.mdx b/src/pages/docs/livesync/index.mdx
index 8b145df32f..bc4428492b 100644
--- a/src/pages/docs/livesync/index.mdx
+++ b/src/pages/docs/livesync/index.mdx
@@ -19,7 +19,7 @@ Ably's [pub/sub channels](/docs/channels) are the mechanism used by LiveSync for
 
 ## Hosted database connectors <a id="hosted"/>
 
-Take advantage of the Ably hosted database connectors to automatically publish changes from your database as messages on Ably channels. The hosted database connectors support controlling which events are routed to which channels, and using Ably's [Auth](/docs/auth) and [Capabilities](/docs/auth/capabilities) you can control which channels a client is allowed to access.
+Take advantage of the Ably hosted database connectors to automatically publish changes from your database as messages on Ably channels. The hosted database connectors support controlling which events are routed to which channels, and using Ably's [Auth](/docs/platform/auth) and [Capabilities](/docs/platform/auth/capabilities) you can control which channels a client is allowed to access.
 
 Ably provides hosted connectors for:
 * [Postgres](/docs/livesync/postgres)
diff --git a/src/pages/docs/livesync/mongodb/index.mdx b/src/pages/docs/livesync/mongodb/index.mdx
index 24d35dc975..5bd34db41a 100644
--- a/src/pages/docs/livesync/mongodb/index.mdx
+++ b/src/pages/docs/livesync/mongodb/index.mdx
@@ -16,7 +16,7 @@ By using Ably Pub/Sub channels and SDKs, clients subscribing to messages publish
 
 The MongoDB database connector is enabled through an Ably integration rule. The rule will consume document changes from your MongoDB deployment via the MongoDB [Change Streams API](https://www.mongodb.com/docs/manual/changeStreams/). The integration rule exists as a "database connector" component that is entirely provisioned and managed by Ably and is fault-tolerant with automatic fail-over.
 
-When a change event is received over the Change Streams API it is published to an Ably channel. When you configure the integration rule, you can specify how change events are mapped to individual Ably channels. Clients can then subscribe to database changes by subscribing to Ably channels. Ably [Auth](/docs/auth) and [Capabilities](/docs/auth/capabilities) control which channels a client can interact with.
+When a change event is received over the Change Streams API it is published to an Ably channel. When you configure the integration rule, you can specify how change events are mapped to individual Ably channels. Clients can then subscribe to database changes by subscribing to Ably channels. Ably [Auth](/docs/platform/auth) and [Capabilities](/docs/platform/auth/capabilities) control which channels a client can interact with.
 
 ## Integration rule <a id="integration-rule"/>
 
@@ -106,9 +106,9 @@ The following is an example of a MongoDB change event that will be carried in th
 For the full schema and fields available on each type of change event, see the MongoDB [Change Event schema](https://www.mongodb.com/docs/v8.0/reference/change-events/) docs.
 </Aside>
 
-In the above example the client is using [basic authentication](/docs/auth/basic). In production applications your clients should use [token authentication](/docs/auth/token).
+In the above example the client is using [basic authentication](/docs/platform/auth/basic). In production applications your clients should use [token authentication](/docs/platform/auth/token).
 
-Clients require the `subscribe` [capability](/docs/auth/capabilities#capabilities-token) for the channels that your integration rule is publishing to.
+Clients require the `subscribe` [capability](/docs/platform/auth/capabilities#capabilities-token) for the channels that your integration rule is publishing to.
 
 The following is an example capability for subscribing to the `myDocuments` channel:
 
diff --git a/src/pages/docs/livesync/postgres/models.mdx b/src/pages/docs/livesync/postgres/models.mdx
index b674a248e8..2a66624975 100644
--- a/src/pages/docs/livesync/postgres/models.mdx
+++ b/src/pages/docs/livesync/postgres/models.mdx
@@ -24,13 +24,13 @@ The following diagram provides a simplified overview of the Models SDK:
 
 ## Authenticate <a id="authenticate"/>
 
-An [API key](/docs/auth#api-keys) is required for your frontend app to authenticate with Ably. API keys are used either to authenticate directly with Ably using [basic authentication](/docs/auth/basic), or to generate tokens for untrusted clients using [token authentication](/docs/auth/token).
+An [API key](/docs/platform/auth#api-keys) is required for your frontend app to authenticate with Ably. API keys are used either to authenticate directly with Ably using [basic authentication](/docs/platform/auth/basic), or to generate tokens for untrusted clients using [token authentication](/docs/platform/auth/token).
 
 <Aside data-type='important'>
-The code examples shown as part of the documentation use [basic authentication](/docs/auth/basic) to demonstrate features for convenience. In your own applications, basic authentication should never be used on the client-side as it exposes your Ably API key. Instead use [token authentication](/docs/auth/token).
+The code examples shown as part of the documentation use [basic authentication](/docs/platform/auth/basic) to demonstrate features for convenience. In your own applications, basic authentication should never be used on the client-side as it exposes your Ably API key. Instead use [token authentication](/docs/platform/auth/token).
 </Aside>
 
-API keys and tokens have a set of [capabilities](/docs/auth/capabilities) assigned to them that specify which operations, such as `subscribe` or `publish` can be performed on which resources. To use the Models SDK, the API key requires the following capabilities, these two capabilities are discussed further down the page, but for the time being set these two and you can review them further along:
+API keys and tokens have a set of [capabilities](/docs/platform/auth/capabilities) assigned to them that specify which operations, such as `subscribe` or `publish` can be performed on which resources. To use the Models SDK, the API key requires the following capabilities, these two capabilities are discussed further down the page, but for the time being set these two and you can review them further along:
 
 * `subscribe` for the channels you intend to subscribe to.
 * `history` if you intend to [sync from historical messages](#replay-from-history).
@@ -382,7 +382,7 @@ By default, the events in the buffer are ordered numerically if the `message.id`
 
 ### Channels and models <a id="design-channels-models"/>
 
-In general, when designing your channels and models, aim for a 1:1:1 relationship between channels, models, and your domain model objects. Channels facilitate data partitioning and access control. For instance, in a task management app, each task can be represented by a model with its own channel, ensuring updates are specific to each task. Ably's [capabilities](/docs/auth/capabilities) are applied on a per channel basis allowing fine-grained access control for each data model in your application.
+In general, when designing your channels and models, aim for a 1:1:1 relationship between channels, models, and your domain model objects. Channels facilitate data partitioning and access control. For instance, in a task management app, each task can be represented by a model with its own channel, ensuring updates are specific to each task. Ably's [capabilities](/docs/platform/auth/capabilities) are applied on a per channel basis allowing fine-grained access control for each data model in your application.
 
 For infrequently updated models, grouping them on the same channel may be viable, while frequently changing models benefit from individual channels. Starting with one channel per model and one model per domain object is a good baseline, adjusting as needed.
 
diff --git a/src/pages/docs/livesync/postgres/quickstart.mdx b/src/pages/docs/livesync/postgres/quickstart.mdx
index 726a6f83af..e6ded73625 100644
--- a/src/pages/docs/livesync/postgres/quickstart.mdx
+++ b/src/pages/docs/livesync/postgres/quickstart.mdx
@@ -17,7 +17,7 @@ git clone https://github.com/ably-labs/live-comments.git
 
 ### Create an Ably account <a id="step-1"/>
 
-[Sign up](https://ably.com/signup) for a free account to get your own API key. Ensure that your API key includes the `subscribe` and `publish` [capabilities](/docs/auth/capabilities).
+[Sign up](https://ably.com/signup) for a free account to get your own API key. Ensure that your API key includes the `subscribe` and `publish` [capabilities](/docs/platform/auth/capabilities).
 
 ### Set up a database <a id="step-2"/>
 
diff --git a/src/pages/docs/messages/annotations.mdx b/src/pages/docs/messages/annotations.mdx
index 2a53dd08e2..711d5f11f2 100644
--- a/src/pages/docs/messages/annotations.mdx
+++ b/src/pages/docs/messages/annotations.mdx
@@ -49,7 +49,7 @@ The `total.v1` summarization method counts the number of annotations of a given
 
 Deleting an annotation decrements the total count for that message.
 
-Using `total.v1` does not attribute counts to individual clients in the summary; it maintains only a simple count per annotation type and does not organize counts by name. [Unidentified](/docs/auth/identified-clients#unidentified) clients can publish `total.v1` annotations. Use the [identified channel rule](/docs/channels#rules) if you want to prevent unidentified clients from publishing annotations.
+Using `total.v1` does not attribute counts to individual clients in the summary; it maintains only a simple count per annotation type and does not organize counts by name. [Unidentified](/docs/platform/auth/identified-clients#unidentified) clients can publish `total.v1` annotations. Use the [identified channel rule](/docs/channels#rules) if you want to prevent unidentified clients from publishing annotations.
 
 If the same client publishes an annotation of a given type to the same message twice, the `total` count is incremented twice.
 
@@ -65,7 +65,7 @@ If the same client publishes an annotation of a given type to the same message t
 
 ### Flag
 
-The `flag.v1` summarization method counts how many distinct clients have published an annotation of a given type and maintains a list of those `clientId`s. Clients must be [identified](/docs/auth/identified-clients) to publish `flag.v1` annotations.
+The `flag.v1` summarization method counts how many distinct clients have published an annotation of a given type and maintains a list of those `clientId`s. Clients must be [identified](/docs/platform/auth/identified-clients) to publish `flag.v1` annotations.
 
 Deleting an annotation decrements the total count for that message and removes the `clientId` from the list of clients that contributed to the summary.
 
@@ -85,7 +85,7 @@ A given client can contribute to the summary only once per annotation type.
 
 ### Distinct
 
-The `distinct.v1` summarization method counts how many unique clients have published an annotation with a given `name` for each annotation type along with the corresponding list of `clientId`s that published it. Clients must be [identified](/docs/auth/identified-clients) to publish `distinct.v1` annotations.
+The `distinct.v1` summarization method counts how many unique clients have published an annotation with a given `name` for each annotation type along with the corresponding list of `clientId`s that published it. Clients must be [identified](/docs/platform/auth/identified-clients) to publish `distinct.v1` annotations.
 
 A given client can contribute to the summary for a particular annotation `name` only once, but the same client may publish additional annotations with different `name`s.
 
@@ -112,7 +112,7 @@ Deleting an annotation removes the `clientId` from the list of clients that cont
 
 ### Unique
 
-The `unique.v1` summarization method counts how many unique clients have published an annotation with a given `name` for each annotation type, while guaranteeing that each client contributes to the summary for only one `name` at a time. The summary for each annotation `name` holds a `total` count of the number of distinct clients that have published an annotation with that `name` along with the corresponding list of `clientId`s that published it. Clients must be [identified](/docs/auth/identified-clients) to publish `unique.v1` annotations.
+The `unique.v1` summarization method counts how many unique clients have published an annotation with a given `name` for each annotation type, while guaranteeing that each client contributes to the summary for only one `name` at a time. The summary for each annotation `name` holds a `total` count of the number of distinct clients that have published an annotation with that `name` along with the corresponding list of `clientId`s that published it. Clients must be [identified](/docs/platform/auth/identified-clients) to publish `unique.v1` annotations.
 
 A given client can contribute to the summary for a particular annotation `name` only once. Publishing an annotation with a different `name` automatically removes that client from the summary for the previous `name` and adds them to the new one, updating the affected total values and list of `clientId`s.
 
@@ -180,7 +180,7 @@ Deleting an annotation removes all contributions made by that `clientId` for tha
 
 To publish an annotation for a message, use the `annotations.publish()` method on a channel. Pass in either a [message](/docs/messages) instance or the `serial` of the message to annotate. This method will publish an annotation with the action `annotation.create`.
 
-Certain annotation summarization methods require a client to be [identified](/docs/auth/identified-clients) for them to be able to publish an annotation. Their `clientId` will then be included in the associated published annotation.
+Certain annotation summarization methods require a client to be [identified](/docs/platform/auth/identified-clients) for them to be able to publish an annotation. Their `clientId` will then be included in the associated published annotation.
 
 Specify the [annotation type](#annotation-types) using the `type` field of the annotation object.
 
diff --git a/src/pages/docs/messages/index.mdx b/src/pages/docs/messages/index.mdx
index f148ff6eee..572d61910f 100644
--- a/src/pages/docs/messages/index.mdx
+++ b/src/pages/docs/messages/index.mdx
@@ -28,7 +28,7 @@ The following are the properties of a message:
 | **name** | The name of the message |
 | **data** | The contents of the message. Also known as the message payload |
 | **id** | Each message sent through Ably is assigned a unique ID, unless you provide your own ID, which serves as the [idempotency key](/docs/pub-sub/advanced#idempotency) |
-| **clientId** | The [ID of the client](/docs/auth/identified-clients) that published the message |
+| **clientId** | The [ID of the client](/docs/platform/auth/identified-clients) that published the message |
 | **connectionId** | The ID of the connection used to publish the message |
 | **timestamp** | The timestamp of when the message was first received by Ably, as milliseconds since the Unix epoch |
 | **extras** | A JSON object of arbitrary key-value pairs that may contain metadata, and/or ancillary payloads. Valid payloads include those related to [Push Notifications](/docs/push), [deltas](/docs/channels/options/deltas) and headers |
diff --git a/src/pages/docs/messages/updates-deletes.mdx b/src/pages/docs/messages/updates-deletes.mdx
index 6338504eac..47a2005afb 100644
--- a/src/pages/docs/messages/updates-deletes.mdx
+++ b/src/pages/docs/messages/updates-deletes.mdx
@@ -199,11 +199,11 @@ Ably may opportunistically discard out of date updates to a given message, for e
 
 #### Capabilities <a id="update-capabilities"/>
 
-To update messages, clients need one of the following [capabilities](/docs/auth/capabilities):
+To update messages, clients need one of the following [capabilities](/docs/platform/auth/capabilities):
 
 | Capability | Description |
 | ---------- | ----------- |
-| **message-update-own** | Can update your own messages (more precisely, messages where the original publisher's `clientId` matches the updater's `clientId`, where both are [identified](/docs/auth/identified-clients)). |
+| **message-update-own** | Can update your own messages (more precisely, messages where the original publisher's `clientId` matches the updater's `clientId`, where both are [identified](/docs/platform/auth/identified-clients)). |
 | **message-update-any** | Can update any message on the channel. |
 
 #### Operation metadata <a id="operation-metadata"/>
@@ -380,11 +380,11 @@ Since deletes are just updates with a different action, [as with updates](#updat
 
 #### Capabilities <a id="delete-capabilities"/>
 
-To delete messages, clients need one of the following [capabilities](/docs/auth/capabilities):
+To delete messages, clients need one of the following [capabilities](/docs/platform/auth/capabilities):
 
 | Capability | Description |
 | ---------- | ----------- |
-| **message-delete-own** | Can delete your own messages (more precisely, messages where the original publisher's `clientId` matches the deleter's `clientId`, where both are [identified](/docs/auth/identified-clients)). |
+| **message-delete-own** | Can delete your own messages (more precisely, messages where the original publisher's `clientId` matches the deleter's `clientId`, where both are [identified](/docs/platform/auth/identified-clients)). |
 | **message-delete-any** | Can delete any message on the channel. |
 
 #### Operation metadata <a id="operation-metadata"/>
@@ -589,11 +589,11 @@ Ably may also at any point deliver an append to subscribers as a `message.update
 
 #### Capabilities <a id="append-capabilities"/>
 
-To append to messages, clients need one of the following [capabilities](/docs/auth/capabilities):
+To append to messages, clients need one of the following [capabilities](/docs/platform/auth/capabilities):
 
 | Capability | Description |
 | ---------- | ----------- |
-| **message-update-own** | Can append to your own messages (more precisely, messages where the original publisher's `clientId` matches your `clientId`, where both are [identified](/docs/auth/identified-clients)). |
+| **message-update-own** | Can append to your own messages (more precisely, messages where the original publisher's `clientId` matches your `clientId`, where both are [identified](/docs/platform/auth/identified-clients)). |
 | **message-update-any** | Can append to any message on the channel. |
 
 #### Operation metadata <a id="append-operation-metadata"/>
@@ -635,7 +635,7 @@ The exact conflation behavior depends on timing and batching intervals, but subs
 
 To retrieve the most recent version of a specific message, use the `getMessage()` method on a REST channel. You can pass either the message's serial identifier as a string, or a message object with a `serial` property.
 
-This operation requires the history [capability](/docs/auth/capabilities).
+This operation requires the history [capability](/docs/platform/auth/capabilities).
 
 <Code>
 ```javascript
@@ -701,7 +701,7 @@ message = await channel.get_message(serial)
 
 To retrieve all historical versions of a message, use the `getMessageVersions()` method. This returns a paginated result containing all versions of the message, including the original and all subsequent updates or delete operations, ordered by version.
 
-This operation requires the history [capability](/docs/auth/capabilities).
+This operation requires the history [capability](/docs/platform/auth/capabilities).
 
 <Code>
 ```javascript
diff --git a/src/pages/docs/metadata-stats/metadata/rest.mdx b/src/pages/docs/metadata-stats/metadata/rest.mdx
index bb9fda5836..bee309f96b 100644
--- a/src/pages/docs/metadata-stats/metadata/rest.mdx
+++ b/src/pages/docs/metadata-stats/metadata/rest.mdx
@@ -27,7 +27,7 @@ curl https://main.realtime.ably.net/channels/<channelId> \
 </Code>
 
 <Aside data-type='important'>
-The `channel-metadata` [capability](/docs/auth/capabilities) is required to retrieve the metadata of a channel.
+The `channel-metadata` [capability](/docs/platform/auth/capabilities) is required to retrieve the metadata of a channel.
 </Aside>
 
 ## Retrieve a list of channels <a id="enumerate"/>
@@ -56,7 +56,7 @@ curl https://main.realtime.ably.net/channels \
 Note that this API is intended for occasional use only. For example, to get an initial set of active channels that will be kept up-to-date using the [`[meta]channel.lifecycle`](/docs/metadata-stats/metadata/subscribe#channel-lifecycle) metachannel. The API is heavily rate-limited and only a single in-flight call is permitted to execute at any time. Further concurrent calls will be refused with the error code `42912`.
 
 <Aside data-type='important'>
-The `channel-metadata` [capability](/docs/auth/capabilities) for the wildcard resource `'*'` is required to enumerate a list of active channels.
+The `channel-metadata` [capability](/docs/platform/auth/capabilities) for the wildcard resource `'*'` is required to enumerate a list of active channels.
 </Aside>
 
 ### Known limitations <a id="limitations"/>
diff --git a/src/pages/docs/metadata-stats/metadata/subscribe.mdx b/src/pages/docs/metadata-stats/metadata/subscribe.mdx
index ea3184f7c7..bbbf9a4a5b 100644
--- a/src/pages/docs/metadata-stats/metadata/subscribe.mdx
+++ b/src/pages/docs/metadata-stats/metadata/subscribe.mdx
@@ -24,7 +24,7 @@ The following is a list of available metachannels:
 | **[meta]log:push** | [log](#log): Similar to `[meta]log`, but only for errors that occur during delivery of Push Notifications |
 
 <Aside data-type='important'>
-[Capabilities](/docs/auth/capabilities) for metachannels work almost identically to how they do for regular channels. The only difference is that the resource name in the capability must explicitly include the `[meta]` qualifier.
+[Capabilities](/docs/platform/auth/capabilities) for metachannels work almost identically to how they do for regular channels. The only difference is that the resource name in the capability must explicitly include the `[meta]` qualifier.
 </Aside>
 
 It is never possible to publish or be present on a metachannel, however you can query their [history](/docs/storage-history/history).
diff --git a/src/pages/docs/metadata-stats/stats.mdx b/src/pages/docs/metadata-stats/stats.mdx
index 87df7857cb..2c079af359 100644
--- a/src/pages/docs/metadata-stats/stats.mdx
+++ b/src/pages/docs/metadata-stats/stats.mdx
@@ -650,7 +650,7 @@ Channel metrics include all active [channels](/docs/channels) that are used to s
 
 ### API requests <a id="api"/>
 
-API request metrics include all HTTP requests made to Ably, including those related to [token authentication](/docs/auth/token) and [push notifications](/docs/push). They do not include those requests made to the [Control API](/docs/platform/account/control-api).
+API request metrics include all HTTP requests made to Ably, including those related to [token authentication](/docs/platform/auth/token) and [push notifications](/docs/push). They do not include those requests made to the [Control API](/docs/platform/account/control-api).
 
 | Metric | Description |
 | --- | --- |
diff --git a/src/pages/docs/platform/account/app/api.mdx b/src/pages/docs/platform/account/app/api.mdx
index 2421063578..5e25462b5a 100644
--- a/src/pages/docs/platform/account/app/api.mdx
+++ b/src/pages/docs/platform/account/app/api.mdx
@@ -9,7 +9,7 @@ redirect_from:
 The API keys tab lists all API keys associated with your account and provides information on each key's capabilities and restrictions. You can [create a new API key](#create) and manage an existing one.
 
 <Aside data-type='note'>
-Before setting up multiple API keys with different permissions or sharing API keys with untrusted parties, consider using [token authentication](/docs/auth/token) instead. Token authentication provides more flexible access control and better security for client-side applications.
+Before setting up multiple API keys with different permissions or sharing API keys with untrusted parties, consider using [token authentication](/docs/platform/auth/token) instead. Token authentication provides more flexible access control and better security for client-side applications.
 </Aside>
 
 ## Create a new API key <a id="create"/>
@@ -20,11 +20,11 @@ The following steps create a new API Key:
   * Assign a friendly name.
   * Give the new API key a descriptive name (e.g. chat app key) so it is easy to identify later.
 
-To manage an API key: set [capabilities](/docs/auth/capabilities), define resource restrictions, use revocable tokens for security, and adjust key settings as needed.
+To manage an API key: set [capabilities](/docs/platform/auth/capabilities), define resource restrictions, use revocable tokens for security, and adjust key settings as needed.
 
 ### Capabilities
 
-[Capabilities](/docs/auth/capabilities) provide permissions required for managing message flow, user presence, notifications, channel information, and access controls, these depend on what you require the API key to have access to:
+[Capabilities](/docs/platform/auth/capabilities) provide permissions required for managing message flow, user presence, notifications, channel information, and access controls, these depend on what you require the API key to have access to:
 
 | Capability | Description |
 | ---------- | ----------- |
@@ -48,15 +48,15 @@ Set resource restrictions to control access to channels and queues, ranging from
 | Only queues | Access any queue but not channels. |
 | Selected channels and queues | Specify explicit rules for access. |
 
-When specifying selected channels and queues, you can provide a comma-separated list of resources. Each resource can match a single channel (e.g., `channel-name`) or multiple channels using wildcards (e.g., `namespace:*`). Queues use the prefix `[queue]` and meta channels use `[meta]`. See [capabilities documentation](/docs/auth/capabilities#wildcards) for detailed wildcard syntax.
+When specifying selected channels and queues, you can provide a comma-separated list of resources. Each resource can match a single channel (e.g., `channel-name`) or multiple channels using wildcards (e.g., `namespace:*`). Queues use the prefix `[queue]` and meta channels use `[meta]`. See [capabilities documentation](/docs/platform/auth/capabilities#wildcards) for detailed wildcard syntax.
 
 <Aside data-type='important'>
-A single API key cannot support complex permission combinations, such as publish access on one channel and subscribe access on another. For such requirements, use [token authentication](/docs/auth/token) instead.
+A single API key cannot support complex permission combinations, such as publish access on one channel and subscribe access on another. For such requirements, use [token authentication](/docs/platform/auth/token) instead.
 </Aside>
 
 ### Revocable tokens
 
-[Revocable tokens](/docs/auth/revocation#revocable-tokens) enhance security by allowing shorter token lifetimes and the ability to revoke tokens issued via the API key.
+[Revocable tokens](/docs/platform/auth/revocation#revocable-tokens) enhance security by allowing shorter token lifetimes and the ability to revoke tokens issued via the API key.
 
 | Option | Description |
 | ------ | ----------- |
diff --git a/src/pages/docs/platform/account/control-api.mdx b/src/pages/docs/platform/account/control-api.mdx
index 844f23f165..d6526d7627 100644
--- a/src/pages/docs/platform/account/control-api.mdx
+++ b/src/pages/docs/platform/account/control-api.mdx
@@ -142,7 +142,7 @@ In the [Ably dashboard](https://ably.com/accounts/any) select the app you want t
 
 ![Application Settings](../../../../images/content/screenshots/control-api/application-settings.png)
 
-The **App ID** is displayed under **Application settings**. It is also the first part of your API key for that app. For example, if your API key is `28AB6c.DEFi0Q`, then the App ID is `28AB6c`. You can find out more in the Ably Help Center article [what is an app API key?](/docs/auth#api-key).
+The **App ID** is displayed under **Application settings**. It is also the first part of your API key for that app. For example, if your API key is `28AB6c.DEFi0Q`, then the App ID is `28AB6c`. You can find out more in the Ably Help Center article [what is an app API key?](/docs/platform/auth#api-key).
 
 ## Examples <a id="examples"/>
 
@@ -463,7 +463,7 @@ You can use the Control API to manage Ably API keys. The main operations are:
 * Update a key
 * Revoke a key
 
-Control API enables you to create a key that has different [capabilities](/docs/auth/capabilities) for different channels.
+Control API enables you to create a key that has different [capabilities](/docs/platform/auth/capabilities) for different channels.
 
 #### List API keys <a id="examples-keys-list"/>
 
diff --git a/src/pages/docs/platform/account/enterprise-customization.mdx b/src/pages/docs/platform/account/enterprise-customization.mdx
index 92197df19d..cfcb397ca6 100644
--- a/src/pages/docs/platform/account/enterprise-customization.mdx
+++ b/src/pages/docs/platform/account/enterprise-customization.mdx
@@ -67,7 +67,7 @@ To use a custom endpoint, perform the following steps:
 
 ### Decide whether to use an Ably subdomain, or your own domain
 
-Ably client libraries connect to the `main.realtime.ably.net` domain by default. This domain is used by both WebSocket and other realtime connections from the Ably client libraries, as well as all REST-based requests. It is optimized for all standard HTTP-based request types, including all [REST requests](/docs/api/rest-api), [authentication requests](/docs/auth), and Comet and JSONP fallback when WebSockets cannot be used.
+Ably client libraries connect to the `main.realtime.ably.net` domain by default. This domain is used by both WebSocket and other realtime connections from the Ably client libraries, as well as all REST-based requests. It is optimized for all standard HTTP-based request types, including all [REST requests](/docs/api/rest-api), [authentication requests](/docs/platform/auth), and Comet and JSONP fallback when WebSockets cannot be used.
 
 When you request a custom endpoint, you have the following options:
 
diff --git a/src/pages/docs/platform/account/users.mdx b/src/pages/docs/platform/account/users.mdx
index ad020cdaba..496b46f06a 100644
--- a/src/pages/docs/platform/account/users.mdx
+++ b/src/pages/docs/platform/account/users.mdx
@@ -29,7 +29,7 @@ User roles have the following permissions:
 | Configure own [2FA](/docs/platform/account/2fa) | ✓ | - | ✓ | ✓ |
 | [Invite new users](#invite) | - | - | ✓ | ✓ |
 | [Remove existing users](#remove) | - | - | ✓ | ✓ |
-| Manage [API keys](/docs/auth) | - | - | ✓ | ✓ |
+| Manage [API keys](/docs/platform/auth) | - | - | ✓ | ✓ |
 | Manage app configuration | - | - | ✓ | ✓ |
 | Manage app settings | - | - | ✓ | ✓ |
 | Create apps | - | - | ✓ | ✓ |
diff --git a/src/pages/docs/platform/ai-llms/index.mdx b/src/pages/docs/platform/ai-llms/index.mdx
index 74d43acf7f..3eb0d2e2d3 100644
--- a/src/pages/docs/platform/ai-llms/index.mdx
+++ b/src/pages/docs/platform/ai-llms/index.mdx
@@ -16,7 +16,7 @@ Every documentation page is available as clean markdown by appending `.md` to th
 
 - `https://ably.com/docs/channels.md` - Channels documentation
 - `https://ably.com/docs/chat/rooms.md` - Chat rooms documentation
-- `https://ably.com/docs/auth.md` - Authentication documentation
+- `https://ably.com/docs/platform/auth.md` - Authentication documentation
 
 These markdown versions strip out navigation and UI elements, providing clean content that LLMs can easily parse and understand.
 
@@ -112,7 +112,7 @@ Use **API reference docs** when:
 
 Never infer or approximate APIs—always rely on API reference pages.
 
-#### Product and feature docs (`/docs/{product}/`, `/docs/channels/`, `/docs/auth/`, etc.)
+#### Product and feature docs (`/docs/{product}/`, `/docs/channels/`, `/docs/platform/auth/`, etc.)
 Use **product and feature docs** for:
 - Understanding how specific features work
 - Configuration options and parameters
diff --git a/src/pages/docs/platform/errors/codes.mdx b/src/pages/docs/platform/errors/codes.mdx
index fe7da183e2..b9522c0886 100644
--- a/src/pages/docs/platform/errors/codes.mdx
+++ b/src/pages/docs/platform/errors/codes.mdx
@@ -48,11 +48,11 @@ Additional examples of the `40003` error code output include:
 * **40003: Excessive value for TTL**
 This error occurs when the [TTL](/docs/api/rest-sdk/authentication#token-request) set for a token parameter exceeds the maximum allowed value of 24 hours.
 * **40003: Excessive value for TTL (revocation is enabled on this key)**
-This error occurs when [revocation](/docs/auth/revocation#revocable-tokens) is enabled, revocable tokens are limited to a TTL of 1 hour instead of 24 hours.
+This error occurs when [revocation](/docs/platform/auth/revocation#revocable-tokens) is enabled, revocable tokens are limited to a TTL of 1 hour instead of 24 hours.
 
 ## 40005: Invalid credentials <a id="40005"/>
 
-This error occurs when the [API key](/docs/auth#api-keys) or [token](/docs/auth/token) used to initialize the library is invalid.
+This error occurs when the [API key](/docs/platform/auth#api-keys) or [token](/docs/platform/auth/token) used to initialize the library is invalid.
 Resolution: The following steps can help resolve this issue:
 
 * API key initialization:
@@ -60,7 +60,7 @@ Resolution: The following steps can help resolve this issue:
 ** In your [Ably dashboard](https://ably.com/accounts/any) to the **API keys** tab.
 ** Use one of these API keys instead of your current one or create a [new API key](/docs/platform/account/app/api#create) with the necessary permissions and privileges and use that to instance the SDK.
 * Token initialization:
-**  If you are using [token authentication](/docs/auth/token), ensure you are correctly requesting a valid token before using it with Ably.
+**  If you are using [token authentication](/docs/platform/auth/token), ensure you are correctly requesting a valid token before using it with Ably.
 
 ## 40006: Invalid connectionId <a id="40006"/>
 
@@ -85,11 +85,11 @@ This error occurs when using the channel [enumeration](/docs/api/rest-api#enumer
 
 ## 40012: Invalid `clientId` <a id="40012"/>
 
-This error occurs when a `clientId` is invalid due to disallowed characters or a mismatch between the `clientId` specified in the request and the one assigned in the authentication [token](/docs/auth/token).
+This error occurs when a `clientId` is invalid due to disallowed characters or a mismatch between the `clientId` specified in the request and the one assigned in the authentication [token](/docs/platform/auth/token).
 
 Examples of this error are when:
 
-* The client attempts to use `*` as a `clientId`, which is not allowed because `*` is used as a [wildcard](/docs/auth/capabilities#wildcards) in capability expressions.
+* The client attempts to use `*` as a `clientId`, which is not allowed because `*` is used as a [wildcard](/docs/platform/auth/capabilities#wildcards) in capability expressions.
 * A client tries to assume an ID of `foo` for an operation, but the token they are using specifies an ID of `bar`.
 
 ## 40013: Invalid message data or encoding <a id="40013"/>
@@ -143,7 +143,7 @@ Examples of this error include attempting to create a resource that already exis
 
 Resolution: The following steps can help resolve this issue:
 * Ensure that an app with the requested name does not already exist in your account. If it does, use a different name.
-* Verify that the [capabilities](/docs/auth/capabilities#capability-operations) listed in the request are valid when creating an API key.
+* Verify that the [capabilities](/docs/platform/auth/capabilities#capability-operations) listed in the request are valid when creating an API key.
 
 ## 40023: Action requires a newer protocol version <a id="40023"/>
 
@@ -179,11 +179,11 @@ const extras = {
 
 ## 40100: Unauthorized <a id="40100"/>
 
-This error occurs when an action cannot be performed due to a lack of [authentication](/docs/auth). There will be additional info in the `message` property about the reason the action could not be performed.
+This error occurs when an action cannot be performed due to a lack of [authentication](/docs/platform/auth). There will be additional info in the `message` property about the reason the action could not be performed.
 
 ## 40101: Invalid credentials <a id="40101"/>
 
-This error occurs when [authentication](/docs/auth) credentials are invalid. The specific error message may provide further details about the cause.
+This error occurs when [authentication](/docs/platform/auth) credentials are invalid. The specific error message may provide further details about the cause.
 
 An example of this error is when a signed token request is invalid due to a mismatched cryptographic signature (MAC does not match) or when the `clientId` specified in the Ably SDK does not match the `clientId` in the access token.
 
@@ -205,7 +205,7 @@ Resolution: Review your authentication setup and token request implementation. E
 
 ## 40102: Incompatible credentials <a id="40102"/>
 
-This error occurs when [authentication](/docs/auth) credentials do not match the existing connection, causing the connection to enter the [failed state](/docs/connect/states).
+This error occurs when [authentication](/docs/platform/auth) credentials do not match the existing connection, causing the connection to enter the [failed state](/docs/connect/states).
 
 Examples of this error include:
 
@@ -217,13 +217,13 @@ Examples of this error include:
 
 This error occurs when an API key is used over a non-TLS (unencrypted) connection, which is not permitted due to security risks. API keys are long-lived credentials, making them more vulnerable if exposed. Unlike short-lived tokens, API keys remain valid indefinitely, meaning a compromised key presents a significant security risk.
 
-Non-TLS transports can be inspected by network devices routing traffic between the client and Ably. Ably does not allow API key authentication over non-TLS connections. However, Ably supports [basic authentication](/docs/auth/basic) over TLS and [token authentication](/docs/auth/token) over non-TLS connections.
+Non-TLS transports can be inspected by network devices routing traffic between the client and Ably. Ably does not allow API key authentication over non-TLS connections. However, Ably supports [basic authentication](/docs/platform/auth/basic) over TLS and [token authentication](/docs/platform/auth/token) over non-TLS connections.
 
-Resolution: Select the appropriate [authentication mechanism](/docs/auth#selecting-auth) for your use case.
+Resolution: Select the appropriate [authentication mechanism](/docs/platform/auth#selecting-auth) for your use case.
 
 ## 40104: Timestamp not current <a id="40104"/>
 
-This error occurs when a signed token request sent to Ably is too old. Ably enforces timestamp validation to ensure [`TokenRequest`](/docs/auth/token/ably-tokens#token-request) remain valid for a limited time, reducing the risk of interception and misuse.
+This error occurs when a signed token request sent to Ably is too old. Ably enforces timestamp validation to ensure [`TokenRequest`](/docs/platform/auth/token/ably-tokens#token-request) remain valid for a limited time, reducing the risk of interception and misuse.
 
 Resolutions: The following steps can help resolve this issue:
 * Ensure that the authentication servers clock is accurate when generating signed token requests.
@@ -238,7 +238,7 @@ This error occurs when a signed [token request](/docs/api/realtime-sdk/types#tok
 Examples of this error include:
 * A client sends a signed token request to Ably but does not receive the response due to network issues. If the client automatically retries the HTTP request in a fallback data center, Ably detects the duplicate nonce and rejects it.
 * An authentication server caches and reuses signed token requests instead of generating a unique one for each request.
-* A misconfigured [`authCallback`](/docs/auth/token/jwt#auth-callback) function reuses the same token request on every invocation instead of generating a fresh one.
+* A misconfigured [`authCallback`](/docs/platform/auth/token/jwt#auth-callback) function reuses the same token request on every invocation instead of generating a fresh one.
 * The `tokenRequest` is not renewed. A new token request should be requested from your server at this point:
 
 <Code>
@@ -262,9 +262,9 @@ Resolution: The following steps can help resolve this issue:
 
 ## 40106: Unable to obtain credentials from given parameters <a id="40106"/>
 
-This error occurs when invalid [authentication](/docs/auth) options (key or token) are provided to the Ably SDK, preventing successful authentication.
+This error occurs when invalid [authentication](/docs/platform/auth) options (key or token) are provided to the Ably SDK, preventing successful authentication.
 
-An example of this error is when no [API key](/docs/auth#api-keys) or [token](/docs/auth/token) is supplied, or when an authentication request is made using a token to request another token, instead of an API key.
+An example of this error is when no [API key](/docs/platform/auth#api-keys) or [token](/docs/platform/auth/token) is supplied, or when an authentication request is made using a token to request another token, instead of an API key.
 
 ## 40111: Connection limits exceeded <a id="40111"/>
 
@@ -296,7 +296,7 @@ This error occurs when the application has reached the maximum number of [API ke
 
 ## 40131: Key revoked <a id="40131"/>
 
-This error occurs when the [Ably API key](/docs/auth#api-keys) used to initialize the SDK is no longer valid because it has been [revoked](/docs/auth/revocation) by an admin of the application.
+This error occurs when the [Ably API key](/docs/platform/auth#api-keys) used to initialize the SDK is no longer valid because it has been [revoked](/docs/platform/auth/revocation) by an admin of the application.
 
 Resolution: The following steps can help resolve this issue:
 * If you are an admin, go to the [API keys tab](/docs/platform/account/app/api) in the Ably dashboard to check for valid keys. Use an existing valid key or create a new one with the necessary permissions.
@@ -304,7 +304,7 @@ Resolution: The following steps can help resolve this issue:
 
 ## 40133: Wrong key; cannot revoke tokens with a different key than the one that issued them <a id="40133"/>
 
-This error occurs when the [Ably API key](/docs/auth#api-keys) used to authorize a token [revocation](/docs/auth/revocation) request does not match the key that originally issued the token.
+This error occurs when the [Ably API key](/docs/platform/auth#api-keys) used to authorize a token [revocation](/docs/platform/auth/revocation) request does not match the key that originally issued the token.
 
 Resolution: The following steps can help resolve this issue:
 * Ensure that the public API key ID used in the request matches the key that originally issued the token.
@@ -312,56 +312,56 @@ Resolution: The following steps can help resolve this issue:
 
 ## 40141: Token revoked <a id="40141"/>
 
-This error occurs when attempting to authenticate with a [token](/docs/auth/token) that has been [revoked](/docs/auth/revocation) and is no longer valid.
+This error occurs when attempting to authenticate with a [token](/docs/platform/auth/token) that has been [revoked](/docs/platform/auth/revocation) and is no longer valid.
 
-Resolution: Ensure that you are using a valid, [non-revoked](/docs/auth/revocation). token for authentication. If needed, generate a new token and use it for authorization.
+Resolution: Ensure that you are using a valid, [non-revoked](/docs/platform/auth/revocation). token for authentication. If needed, generate a new token and use it for authorization.
 
 ## 40142: Token expired <a id="40142"/>
 
-This error occurs when the authentication [token](/docs/auth/token/jwt#refresh) has expired and is no longer valid for use.
+This error occurs when the authentication [token](/docs/platform/auth/token/jwt#refresh) has expired and is no longer valid for use.
 
 An example of this error is when a client attempts to authenticate with a token that has exceeded its time-to-live (TTL).
 
 Resolution: The following steps can help resolve this issue:
-* Use [`authUrl`](/docs/auth/token/jwt#auth-url) or [`authCallback`](/docs/auth/token/jwt#auth-callback) in your client configuration to enable automatic token renewal.
+* Use [`authUrl`](/docs/platform/auth/token/jwt#auth-url) or [`authCallback`](/docs/platform/auth/token/jwt#auth-callback) in your client configuration to enable automatic token renewal.
 * If `authUrl` or `authCallback` is correctly configured, the client SDK will automatically renew the token when needed, so you may see this error temporarily before renewal occurs.
 
 ## 40143: Token unrecognized <a id="40143"/>
 
-This error occurs when the provided token is not recognized as a valid Ably [token](/docs/auth/token/ably-tokens), Ably [JWT](/docs/auth/token/jwt), or a JWT containing a valid Ably token.
+This error occurs when the provided token is not recognized as a valid Ably [token](/docs/platform/auth/token/ably-tokens), Ably [JWT](/docs/platform/auth/token/jwt), or a JWT containing a valid Ably token.
 
 An example of this error is when a JWT is incorrectly formatted or when an Ably token does not follow the expected structure, for example: `<appId>.<randomBytes>`. Any token that does not adhere to the correct format will not be recognized.
 
-Resolution: Validate the token format before using it for authentication. If creating a [JWT](/docs/auth/token/jwt), use a standard JWT library to ensure correct generation. If using an Ably token, verify that it matches the expected format as returned from the [`requestToken`](/docs/api/token-request-spec#examples) endpoint.
+Resolution: Validate the token format before using it for authentication. If creating a [JWT](/docs/platform/auth/token/jwt), use a standard JWT library to ensure correct generation. If using an Ably token, verify that it matches the expected format as returned from the [`requestToken`](/docs/api/token-request-spec#examples) endpoint.
 
 ## 40144: Unexpected error decoding JWT; decode exception <a id="40144"/>
 
-This error occurs when the [JWT](/docs/auth/token/jwt). provided for authentication cannot be validated by Ably due to incorrect formatting, missing claims, or unsupported configurations.
+This error occurs when the [JWT](/docs/platform/auth/token/jwt). provided for authentication cannot be validated by Ably due to incorrect formatting, missing claims, or unsupported configurations.
 
-This error occurs when the [JWT](/docs/auth/token/jwt) provided for authentication cannot be validated by Ably. The specific reason for the failure will be available in the reason property of a [`ConnectionStateChange`](/docs/api/realtime-sdk/types#connection-state-change) object or in an error response from a REST request.
+This error occurs when the [JWT](/docs/platform/auth/token/jwt) provided for authentication cannot be validated by Ably. The specific reason for the failure will be available in the reason property of a [`ConnectionStateChange`](/docs/api/realtime-sdk/types#connection-state-change) object or in an error response from a REST request.
 
 Examples of this error include:
 * Missing or invalid payload claims, such as iat (issued at) or exp (expiration).
 * Using a deprecated or unsupported signing algorithm.
 * Providing an empty string for `x-ably-capability`.
-* Using an empty string or non-string value for [`x-ably-revocation-key`](/docs/auth/revocation#revocation-key).
+* Using an empty string or non-string value for [`x-ably-revocation-key`](/docs/platform/auth/revocation#revocation-key).
 * Missing kid (Key ID) when using [JWT authentication with an API key](/docs/api/realtime-sdk/authentication#ably-jwt).
 
 ## 40160: Action not permitted <a id="40160"/>
 
 This error occurs when the client does not have permission to perform the requested action.
 
-An example of this error is when a token request includes an empty [capability object](/docs/auth/capabilities#capabilities-token), for example: `({})`, meaning the client has no assigned permissions, or when the requested [resource](/docs/auth/capabilities#wildcards) does not match the API key's allowed capabilities.
+An example of this error is when a token request includes an empty [capability object](/docs/platform/auth/capabilities#capabilities-token), for example: `({})`, meaning the client has no assigned permissions, or when the requested [resource](/docs/platform/auth/capabilities#wildcards) does not match the API key's allowed capabilities.
 
-Resolution: Ensure the [API key](/docs/auth#api-keys) supports the required [capabilities](/docs/auth/capabilities#capabilities-key) for the requested action.
+Resolution: Ensure the [API key](/docs/platform/auth#api-keys) supports the required [capabilities](/docs/platform/auth/capabilities#capabilities-key) for the requested action.
 
 ## 40161: Access denied to channel: namespace requires identified clients <a id="40161"/>
 
-This error occurs when a [non-identified client](/docs/auth/identified-clients) attempts to access a channel that requires an identified client. Each application's channel namespaces configuration can be found in its application settings. By default, the identified namespace requires a client to be identified.
+This error occurs when a [non-identified client](/docs/platform/auth/identified-clients) attempts to access a channel that requires an identified client. Each application's channel namespaces configuration can be found in its application settings. By default, the identified namespace requires a client to be identified.
 
 ## 40170: Error from client token callback <a id="40170"/>
 
-This error occurs when an authentication attempt using [`authUrl`](/docs/auth/token/jwt#auth-url) or [`authCallback`](/docs/auth/token/jwt#auth-callback) fails due to a timeout, network issue, invalid token format, or another authentication error condition.
+This error occurs when an authentication attempt using [`authUrl`](/docs/platform/auth/token/jwt#auth-url) or [`authCallback`](/docs/platform/auth/token/jwt#auth-callback) fails due to a timeout, network issue, invalid token format, or another authentication error condition.
 
 Examples of this error include when a `TokenRequest` callback times out after the default 10-second limit. Also, when he `authUrl` response is missing a Content-Type header has an unsupported Content-Type.
 
@@ -375,7 +375,7 @@ Resolution: The following steps can help resolve this issue:
 
 ## 40171: No means provided to renew auth token <a id="40171"/>
 
-This error occurs when no [`authUrl`](/docs/auth/token/jwt#auth-url) or [`authCallback`](/docs/auth/token/jwt#auth-callback) is provided in [`clientOptions`](/docs/getting-started#options) when initializing the Ably REST or Realtime SDK.
+This error occurs when no [`authUrl`](/docs/platform/auth/token/jwt#auth-url) or [`authCallback`](/docs/platform/auth/token/jwt#auth-callback) is provided in [`clientOptions`](/docs/getting-started#options) when initializing the Ably REST or Realtime SDK.
 
 Tokens have a set expiration time, and once expired, they are no longer valid for communication with Ably. If `authUrl` or `authCallback` is configured, the SDK will automatically request a new token before expiration, ensuring uninterrupted operation.
 
@@ -624,7 +624,7 @@ Resolution: If you are seeing resumes failing in ably-js, this was a known bug i
 
 ## 80019: Auth server rejecting request <a id="80019"/>
 
-This error occurs when the client library fails to obtain a token using the client-supplied [`authUrl`](/docs/auth/token/jwt#auth-url) or [`authCallback`](/docs/auth/token/jwt#auth-callback). It is raised when the request to the authentication server fails due to an error or exception in the callback.
+This error occurs when the client library fails to obtain a token using the client-supplied [`authUrl`](/docs/platform/auth/token/jwt#auth-url) or [`authCallback`](/docs/platform/auth/token/jwt#auth-callback). It is raised when the request to the authentication server fails due to an error or exception in the callback.
 
 ## 80020: Continuity loss due to maximum subscribe message rate exceeded <a id="80020"/>
 
@@ -686,7 +686,7 @@ This error occurs when the [maximum](/docs/platform/pricing/limits#channel) rate
 This error occurs when a client attempts to [enter](/docs/chat/rooms/presence#set) the [presence](/docs/presence-occupancy/presence) set of a channel without specifying a `clientId`.
 
 A client can be identified in several ways:
-* If using [token](/docs/auth/token) authentication, ensure the token is associated with a `clientId` by setting the `clientId` field in `tokenParams` when creating a token request or requesting a token.
+* If using [token](/docs/platform/auth/token) authentication, ensure the token is associated with a `clientId` by setting the `clientId` field in `tokenParams` when creating a token request or requesting a token.
 * If using basic authentication or token authentication with a wildcard `clientId`, set the `clientId` in the client options when initializing the Ably SDK.
 * Specify a `clientId` at the time of entering presence using [`enterClient()`](/docs/api/realtime-sdk/presence#enterclient).
 
diff --git a/src/pages/docs/platform/integrations/inbound/kafka-connector.mdx b/src/pages/docs/platform/integrations/inbound/kafka-connector.mdx
index e659321385..7c02890cfb 100644
--- a/src/pages/docs/platform/integrations/inbound/kafka-connector.mdx
+++ b/src/pages/docs/platform/integrations/inbound/kafka-connector.mdx
@@ -22,7 +22,7 @@ Install the Ably Kafka Connector from:
 * [GitHub](https://github.com/ably/kafka-connect-ably) to run within your own infrastructure.
 * [Confluent Hub](https://www.confluent.io/hub/ably/kafka-connect-ably) to run on the Confluent Platform.
 
-Once installed, configure it with your [Ably API key](/docs/auth#api-keys) to enable data from Kafka topics to be published into Ably channels.
+Once installed, configure it with your [Ably API key](/docs/platform/auth#api-keys) to enable data from Kafka topics to be published into Ably channels.
 
 ## Mapping <a id="mapping"/>
 
diff --git a/src/pages/docs/platform/integrations/skip-integrations.mdx b/src/pages/docs/platform/integrations/skip-integrations.mdx
index 8fe5f0bc44..58159be1b0 100644
--- a/src/pages/docs/platform/integrations/skip-integrations.mdx
+++ b/src/pages/docs/platform/integrations/skip-integrations.mdx
@@ -11,7 +11,7 @@ Privileged users can skip integrations on a per-message basis, providing greater
 A strong use case for skipping integrations is in chat applications. For example, a moderation service publishes a command telling clients to edit or delete a message. That command should not trigger further moderation events by itself.
 
 <Aside data-type='note'>
-Clients must have the [privileged-headers](/docs/auth/capabilities#capability-operations) capability enabled in their Ably [API key](/docs/auth) or [token](/docs/auth/token) to skip integrations.
+Clients must have the [privileged-headers](/docs/platform/auth/capabilities#capability-operations) capability enabled in their Ably [API key](/docs/platform/auth) or [token](/docs/platform/auth/token) to skip integrations.
 </Aside>
 
 ## Skip all integrations
diff --git a/src/pages/docs/platform/pricing/limits.mdx b/src/pages/docs/platform/pricing/limits.mdx
index 815b13adae..18bd324a8e 100644
--- a/src/pages/docs/platform/pricing/limits.mdx
+++ b/src/pages/docs/platform/pricing/limits.mdx
@@ -136,7 +136,7 @@ Integration limits relate to the rate and concurrency of [webhooks](/docs/platfo
 
 ## API limits <a id="api"/>
 
-API request limits are the maximum number of [REST API](/docs/api/rest-api) requests, [Control API](/docs/platform/account/control-api) requests and [token requests](/docs/auth/token) that can be made to Ably.
+API request limits are the maximum number of [REST API](/docs/api/rest-api) requests, [Control API](/docs/platform/account/control-api) requests and [token requests](/docs/platform/auth/token) that can be made to Ably.
 
 | API request limit | Free | Standard | Pro | Enterprise |
 | ----------------- | ---- | -------- | --- | ---------- |
diff --git a/src/pages/docs/platform/products/index.mdx b/src/pages/docs/platform/products/index.mdx
index 2ae6609da1..056606cfc9 100644
--- a/src/pages/docs/platform/products/index.mdx
+++ b/src/pages/docs/platform/products/index.mdx
@@ -243,7 +243,7 @@ The Chat and Spaces SDKs expose the underlying Ably Realtime client that powers
 
 There are several benefits to this architecture:
 
-* [Authentication](/docs/auth) and [connection management](/docs/connect) are handled by the underlying SDK.
+* [Authentication](/docs/platform/auth) and [connection management](/docs/connect) are handled by the underlying SDK.
 * You maintain a single connection to Ably rather than multiple connections.
 * You can extend your application's functionality with custom Pub/Sub features alongside the purpose-built SDK.
 
@@ -292,5 +292,5 @@ When combining SDKs with Pub/Sub:
 * Follow the [getting started guide](/docs/getting-started) to start building with Ably Pub/Sub.
 * Get started with [Chat](/docs/chat/setup), [Spaces](/docs/spaces/setup), [LiveObjects](/docs/liveobjects), [LiveSync](/docs/livesync), or [AI Transport](/docs/ai-transport).
 * Explore [examples](https://ably.com/examples) to see working implementations of common use cases.
-* Understand [authentication](/docs/auth) before going to production.
+* Understand [authentication](/docs/platform/auth) before going to production.
 * Review [connection management](/docs/connect) for the Realtime interface.
diff --git a/src/pages/docs/presence-occupancy/presence.mdx b/src/pages/docs/presence-occupancy/presence.mdx
index 4251c2518c..a8a3147f52 100644
--- a/src/pages/docs/presence-occupancy/presence.mdx
+++ b/src/pages/docs/presence-occupancy/presence.mdx
@@ -19,7 +19,7 @@ Presence enables clients to be aware of other clients that are currently "presen
 Other devices and services can subscribe to presence events in real time using the realtime interface or with [integrations](/docs/platform/integrations). You can also request a list of clients or devices on a channel at a particular point in time with the REST interface.
 
 <Aside data-type="important">
-Clients must be [identified](/docs/auth/identified-clients) by having a `ClientId` in order to be present on a channel. They also require the `presence` [capability](/docs/auth/capabilities) to enter the presence set, and the `subscribe` capability to subscribe to presence events.
+Clients must be [identified](/docs/platform/auth/identified-clients) by having a `ClientId` in order to be present on a channel. They also require the `presence` [capability](/docs/platform/auth/capabilities) to enter the presence set, and the `subscribe` capability to subscribe to presence events.
 </Aside>
 
 ## Trigger presence events <a id="trigger-events"/>
@@ -623,7 +623,7 @@ Using server-side batching for presence events can reduce message costs when the
 
 ### Be present without subscribing to presence events <a id="present-no-subscribe"/>
 
-Messages are streamed to clients as soon as they [attach](/docs/channels/states#attach) to a channel, as long as they have the [subscribe capability](/docs/auth/capabilities).
+Messages are streamed to clients as soon as they [attach](/docs/channels/states#attach) to a channel, as long as they have the [subscribe capability](/docs/platform/auth/capabilities).
 
 Efficient use of capabilities can prevent clients from receiving presence events while still allowing them to enter the presence set. This is a common scenario when you want lots of people to be present without necessarily listening for presence change events, such as when you just want to know how many people are present on a channel at any point in time.
 
diff --git a/src/pages/docs/protocols/index.mdx b/src/pages/docs/protocols/index.mdx
index 8f4c6a4a2a..00fe40d499 100644
--- a/src/pages/docs/protocols/index.mdx
+++ b/src/pages/docs/protocols/index.mdx
@@ -5,7 +5,7 @@ redirect_from:
   - /docs/protocol-adapters
 ---
 
-Ably SDKs are the recommended method for connecting to Ably because they offer support for a comprehensive set of Ably features, such as automatic [connection management](/docs/connect), [authentication token renewal](/docs/auth/token) and [presence](/docs/presence-occupancy).
+Ably SDKs are the recommended method for connecting to Ably because they offer support for a comprehensive set of Ably features, such as automatic [connection management](/docs/connect), [authentication token renewal](/docs/platform/auth/token) and [presence](/docs/presence-occupancy).
 
 Protocol adapters offer an alternative method for connecting to Ably. The advantage to protocol adapters is that they require fewer resources in terms of memory and network overhead such as in smaller footprint devices, or on a platform where an Ably SDK isn't available such as an Arduino-based IoT wearable. The potential drawback to consider when evaluating protocol adapters is that they do not support the full set of Ably features, for example the MQTT protocol adapter does not support presence, and the SSE protocol adapter does not support automatic token renewal.
 
diff --git a/src/pages/docs/protocols/mqtt.mdx b/src/pages/docs/protocols/mqtt.mdx
index 62779c03e9..c459cf7361 100644
--- a/src/pages/docs/protocols/mqtt.mdx
+++ b/src/pages/docs/protocols/mqtt.mdx
@@ -62,9 +62,9 @@ var client = mqtt.connect('mqtts:main.mqtt.ably.net', options);
 
 ### Token Authentication <a id="token-auth"/>
 
-Ably recommends that you always make use of [token Authentication over basic Authentication](/docs/auth) when trying to connect from devices you may not trust. In addition, if you're using Basic Authentication you'll be required to use SSL to connect to our adapter to ensure the API key cannot be accessed by someone listening in.
+Ably recommends that you always make use of [token Authentication over basic Authentication](/docs/platform/auth) when trying to connect from devices you may not trust. In addition, if you're using Basic Authentication you'll be required to use SSL to connect to our adapter to ensure the API key cannot be accessed by someone listening in.
 
-For Token Authentication you'll be required to [create a token from your own servers](/docs/auth/token). Once you have the token, you can simply pass it through when trying to connect to Ably as the connection's `username`, leaving the `password` empty.
+For Token Authentication you'll be required to [create a token from your own servers](/docs/platform/auth/token). Once you have the token, you can simply pass it through when trying to connect to Ably as the connection's `username`, leaving the `password` empty.
 
 If using Token Authentication, you can subscribe to a special topic, `[mqtt]tokenevents`, to get a warning when the current connection's token is about to expire. This will be a single message, sent 30 seconds before the token expires, with the 13 byte payload `expirywarning`.
 
@@ -160,7 +160,7 @@ In the above example, `command` will now contain the message in its original str
 
 ## SSL/TLS <a id="ssl-tls"/>
 
-Ably supports both SSL and non-SSL connections (the latter uses a different port, see above), but strongly recommends using SSL wherever possible. If you are not using SSL, note that the same restrictions apply as if you were using an Ably client without SSL. That is, [connection attempts using Basic Authentication (i.e. an API key) are disallowed](/docs/auth/basic), and any [namespaces which you've enabled 'require TLS' on](/docs/channels) will be inaccessible. [Contact us](https://ably.com/support) if this is a problem for you.
+Ably supports both SSL and non-SSL connections (the latter uses a different port, see above), but strongly recommends using SSL wherever possible. If you are not using SSL, note that the same restrictions apply as if you were using an Ably client without SSL. That is, [connection attempts using Basic Authentication (i.e. an API key) are disallowed](/docs/platform/auth/basic), and any [namespaces which you've enabled 'require TLS' on](/docs/channels) will be inaccessible. [Contact us](https://ably.com/support) if this is a problem for you.
 
 ## Channel options <a id="channel-options"/>
 
diff --git a/src/pages/docs/protocols/pubnub.mdx b/src/pages/docs/protocols/pubnub.mdx
index 96e0ccc928..03f03bffa9 100644
--- a/src/pages/docs/protocols/pubnub.mdx
+++ b/src/pages/docs/protocols/pubnub.mdx
@@ -78,7 +78,7 @@ pubnub = Pubnub.new(
 </Code>
 
 <Aside data-type='note'>
-PubNub uses different API keys for publishing and subscribing. Ably does not use different keys and instead manages access through API key and token [capabilities](/docs/auth/capabilities). The adapter will use the value passed to `subscribe_key` to create a connection to Ably. If that API key doesn't have publish capabilities, the client won't be able to publish.
+PubNub uses different API keys for publishing and subscribing. Ably does not use different keys and instead manages access through API key and token [capabilities](/docs/platform/auth/capabilities). The adapter will use the value passed to `subscribe_key` to create a connection to Ably. If that API key doesn't have publish capabilities, the client won't be able to publish.
 </Aside>
 
 | Option | Description |
diff --git a/src/pages/docs/protocols/pusher.mdx b/src/pages/docs/protocols/pusher.mdx
index f4661c728f..7f78c1e869 100644
--- a/src/pages/docs/protocols/pusher.mdx
+++ b/src/pages/docs/protocols/pusher.mdx
@@ -28,7 +28,7 @@ The following Pusher features are supported using the adapter:
 The Pusher protocol is not supported by default in Ably apps. This is due to security reasons associated with the use of public channels.
 
 <Aside data-type='important'>
-Normally, it is not possible to connect to Ably without a complete API key, or a [token](/docs/auth/token) derived from one. When the Pusher Adapter is enabled, you can connect to Pusher public channels with only the Ably API [key name](/docs/auth#format). The key name is a combination of the app ID and the key ID.
+Normally, it is not possible to connect to Ably without a complete API key, or a [token](/docs/platform/auth/token) derived from one. When the Pusher Adapter is enabled, you can connect to Pusher public channels with only the Ably API [key name](/docs/platform/auth#format). The key name is a combination of the app ID and the key ID.
 </Aside>
 
 To enable the Pusher Adapter in an app:
@@ -63,7 +63,7 @@ const pusher = new Pusher('appId.keyId', {
 </Code>
 
 <Aside data-type='note'>
-You should only use your [Ably API key name](/docs/auth#format), not the full API key. This includes everything before the colon `:` in your API key.
+You should only use your [Ably API key name](/docs/platform/auth#format), not the full API key. This includes everything before the colon `:` in your API key.
 </Aside>
 
 | Option | Description |
diff --git a/src/pages/docs/protocols/sse.mdx b/src/pages/docs/protocols/sse.mdx
index 4d36c09dcf..dccf3dc2d7 100644
--- a/src/pages/docs/protocols/sse.mdx
+++ b/src/pages/docs/protocols/sse.mdx
@@ -57,11 +57,11 @@ eventSource.onmessage = function(event) {
 
 ## Authentication <a id="auth"/>
 
-Authentication with SSE allows for two methods: [basic auth](/docs/auth/basic) using an [API key](/docs/getting-started) or [token auth](/docs/auth/token), using a token from your server. For enhanced security and control over connections, token auth is recommended for client-side use. Basic auth is simpler as it omits the need for an auth server and the potential need for clients to refresh expired tokens.
+Authentication with SSE allows for two methods: [basic auth](/docs/platform/auth/basic) using an [API key](/docs/getting-started) or [token auth](/docs/platform/auth/token), using a token from your server. For enhanced security and control over connections, token auth is recommended for client-side use. Basic auth is simpler as it omits the need for an auth server and the potential need for clients to refresh expired tokens.
 
-It is possible to use either [basic auth](/docs/auth/basic), with an [API key](/docs/getting-started), or [token auth](/docs/auth/token), with a [token issued from your server](/docs/auth/token), with SSE. It's recommended to use token auth on the client side for [security reasons](/docs/auth), so you have control over who can connect. Basic auth, while lacking this control, is simpler (it doesn't require you to run an auth server), and you don't have to worry about the client obtaining a new token when the old one expires.
+It is possible to use either [basic auth](/docs/platform/auth/basic), with an [API key](/docs/getting-started), or [token auth](/docs/platform/auth/token), with a [token issued from your server](/docs/platform/auth/token), with SSE. It's recommended to use token auth on the client side for [security reasons](/docs/platform/auth), so you have control over who can connect. Basic auth, while lacking this control, is simpler (it doesn't require you to run an auth server), and you don't have to worry about the client obtaining a new token when the old one expires.
 
-If using basic auth, you can use a querystring parameter of `key` or an `Authorization: Basic <base64-encoded key>` header. If using token auth, you can use an `accessToken` querystring parameter or an `Authorization: Bearer <base64-encoded token>` header. See [REST API authentication](/docs/auth) for more information.
+If using basic auth, you can use a querystring parameter of `key` or an `Authorization: Basic <base64-encoded key>` header. If using token auth, you can use an `accessToken` querystring parameter or an `Authorization: Bearer <base64-encoded token>` header. See [REST API authentication](/docs/platform/auth) for more information.
 
 Note that [connection state](/docs/connect) is only retained for two minutes.
 
diff --git a/src/pages/docs/pub-sub/advanced.mdx b/src/pages/docs/pub-sub/advanced.mdx
index 0bb1c6ad7a..c97aaa7bbc 100644
--- a/src/pages/docs/pub-sub/advanced.mdx
+++ b/src/pages/docs/pub-sub/advanced.mdx
@@ -274,7 +274,7 @@ unsubscribe()
 
 ### Attaching versus subscribing <a id="attach-subscribe"/>
 
-Messages are streamed to clients as soon as they attach to a channel, as long as they have the `subscribe` [capability](/docs/auth/capabilities) for it. This is independent of whether or not they have subscribed to the channel.
+Messages are streamed to clients as soon as they attach to a channel, as long as they have the `subscribe` [capability](/docs/platform/auth/capabilities) for it. This is independent of whether or not they have subscribed to the channel.
 
 Subscribing to a channel only registers a listener, or function, client-side that is called each time a message is received. This means that Ably is unaware of whether or not a client is subscribed to a channel.
 
@@ -392,7 +392,7 @@ Subscribing to events server-side using the pub-sub pattern can be disadvantageo
 
 Subscription filters enable you to subscribe to a channel and only receive messages that satisfy a filter expression.
 
-Messages are streamed to clients as soon as they [attach](/docs/channels/states#attach) to a channel, if they have the `subscribe` [capability](/docs/auth/capabilities) for it. Subscription filters apply server-side filtering to messages, meaning that a client will only ever receive the messages that they subscribe to.
+Messages are streamed to clients as soon as they [attach](/docs/channels/states#attach) to a channel, if they have the `subscribe` [capability](/docs/platform/auth/capabilities) for it. Subscription filters apply server-side filtering to messages, meaning that a client will only ever receive the messages that they subscribe to.
 
 Subscription filters are currently in preview status.
 
@@ -687,7 +687,7 @@ await pubChannel.publish({
 
 #### Subscription filter capabilities <a id="filter-capabilities"/>
 
-Clients require the subscribe [capability](/docs/auth/capabilities) for one of the following resources in order to receive messages from a subscription filter:
+Clients require the subscribe [capability](/docs/platform/auth/capabilities) for one of the following resources in order to receive messages from a subscription filter:
 
 * `[filter]<channel name>`
 * `[*]<channel name>`
@@ -1189,7 +1189,7 @@ You can use the REST interface of an Ably SDK to publish messages on behalf of a
 
 To publish on behalf of a realtime connection, the REST publisher requires the [`connectionKey`](/docs/api/realtime-sdk/connection#key) of the realtime client. The `connectionKey` is a secret of the client unless explicitly shared. The REST publisher can then set the `connectionKey` [in the root of the published message](/docs/api/rest-sdk/messages#connection-key).
 
-If the realtime connection is [identified](/docs/auth/identified-clients) by being bound to a `clientId`, then the REST publish must include that same `clientId`. This can be included in [the message itself](/docs/api/rest-sdk/messages#client-id) to apply to only that message, in the case that the REST client is able to assume any `clientId`, or using a REST client bound to that specific `clientId`.
+If the realtime connection is [identified](/docs/platform/auth/identified-clients) by being bound to a `clientId`, then the REST publish must include that same `clientId`. This can be included in [the message itself](/docs/api/rest-sdk/messages#client-id) to apply to only that message, in the case that the REST client is able to assume any `clientId`, or using a REST client bound to that specific `clientId`.
 
 The publish attempt will fail in the following scenarios:
 
diff --git a/src/pages/docs/pub-sub/index.mdx b/src/pages/docs/pub-sub/index.mdx
index 84f20a549d..d5f7b6397c 100644
--- a/src/pages/docs/pub-sub/index.mdx
+++ b/src/pages/docs/pub-sub/index.mdx
@@ -291,7 +291,7 @@ _, err = channel.Subscribe(context.Background(), "myEvent", func(msg *ably.Messa
 
 ## Publish a message <a id="publish"/>
 
-Publishing messages to a channel is how clients communicate with one another. Any subscribers will receive published messages as long as they are subscribed and have the `subscribe` [capability](/docs/auth/capabilities) for that channel.
+Publishing messages to a channel is how clients communicate with one another. Any subscribers will receive published messages as long as they are subscribed and have the `subscribe` [capability](/docs/platform/auth/capabilities) for that channel.
 
 Publishing is an operation available to the realtime and REST interfaces of Pub/Sub SDKs. REST publishing is more efficient if you don't need to establish a persistent [connection](/docs/connect) to Ably, such as to subscribe to messages. For example, if you have a server publishing messages to channels that doesn't need to receive any updates from them.
 
diff --git a/src/pages/docs/push/getting-started/apns.mdx b/src/pages/docs/push/getting-started/apns.mdx
index d63962a217..cefea8825a 100644
--- a/src/pages/docs/push/getting-started/apns.mdx
+++ b/src/pages/docs/push/getting-started/apns.mdx
@@ -980,7 +980,7 @@ Verify that your app receives and handles location push notifications correctly
 ## Next steps <a id="next-steps"/>
 
 * Check the [push example](https://github.com/ably/ably-cocoa/tree/main/Examples/AblyPush)
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Explore [push notification administration](/docs/push/admin) for managing devices and subscriptions.
 * Learn about [channel rules](/docs/push/channel-rules) for channel-based push notifications.
 * Read more about the [Push Admin API](/docs/api/realtime-sdk?lang=swift#push-admin).
diff --git a/src/pages/docs/push/getting-started/fcm.mdx b/src/pages/docs/push/getting-started/fcm.mdx
index ac064d26f1..8decadcf8a 100644
--- a/src/pages/docs/push/getting-started/fcm.mdx
+++ b/src/pages/docs/push/getting-started/fcm.mdx
@@ -815,7 +815,7 @@ Build and run your app again. Use the new buttons to send push notifications dir
 
 ## Next steps <a id="next-steps"/>
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Explore [push notification administration](/docs/push#push-admin) for managing devices and subscriptions.
 * Learn about [channel rules](/docs/channels#rules) for channel-based push notifications.
 * Read more about the [Push Admin API](/docs/api/realtime-sdk/push-admin).
diff --git a/src/pages/docs/push/getting-started/web.mdx b/src/pages/docs/push/getting-started/web.mdx
index 236fc06318..cf01b671e7 100644
--- a/src/pages/docs/push/getting-started/web.mdx
+++ b/src/pages/docs/push/getting-started/web.mdx
@@ -718,7 +718,7 @@ Safari on macOS 13+ supports Web Push, but with some limitations. Notification a
 
 ## Next steps <a id="next-steps"/>
 
-* Understand [token authentication](/docs/auth/token) before going to production.
+* Understand [token authentication](/docs/platform/auth/token) before going to production.
 * Explore [push notification administration](/docs/push#push-admin) for managing devices and subscriptions.
 * Learn about [channel rules](/docs/channels#rules) for channel-based push notifications.
 * Read more about the [Push Admin API](/docs/api/realtime-sdk/push-admin).
diff --git a/src/pages/docs/push/index.mdx b/src/pages/docs/push/index.mdx
index 9fbe5b7fe6..70eb84cb9d 100644
--- a/src/pages/docs/push/index.mdx
+++ b/src/pages/docs/push/index.mdx
@@ -95,7 +95,7 @@ Each push target device or browser is associated with a unique `deviceId` and au
 
 * By utilizing an Ably token containing the device's or browser's `deviceId`.
 
-* By employing a standard [Ably key](/docs/auth/basic) or [Token](/docs/auth/token), with a `deviceIdentityToken`, a credential generated during registration to assert the device's or browser's identity, included in the request header.
+* By employing a standard [Ably key](/docs/platform/auth/basic) or [Token](/docs/platform/auth/token), with a `deviceIdentityToken`, a credential generated during registration to assert the device's or browser's identity, included in the request header.
 
 The service credential management is handled by the [Ably SDK](https://ably.com/docs/sdks), removing the need for the client application to manage device credentials unless accessing the [push admin API](/docs/api/realtime-sdk/push-admin) directly via HTTP.
 
diff --git a/src/pages/docs/spaces/authentication.mdx b/src/pages/docs/spaces/authentication.mdx
index b6d78d0911..11773a59d3 100644
--- a/src/pages/docs/spaces/authentication.mdx
+++ b/src/pages/docs/spaces/authentication.mdx
@@ -262,5 +262,5 @@ await realtimeClient.auth.authorize();
 ```
 </Code>
 
-- To immediately remove access, [revoke issued tokens](/docs/auth/revocation).
-- If your capability JSON is too large for JWT or must remain confidential, use native [Ably Tokens](/docs/auth/token/ably-tokens).
+- To immediately remove access, [revoke issued tokens](/docs/platform/auth/revocation).
+- If your capability JSON is too large for JWT or must remain confidential, use native [Ably Tokens](/docs/platform/auth/token/ably-tokens).
diff --git a/src/pages/docs/spaces/avatar.mdx b/src/pages/docs/spaces/avatar.mdx
index fd148ec7df..c774009517 100644
--- a/src/pages/docs/spaces/avatar.mdx
+++ b/src/pages/docs/spaces/avatar.mdx
@@ -96,7 +96,7 @@ The following are the properties of a member event payload:
 
 | Property | Description| Type |
 | -------- | ---------- | ---- |
-| clientId | The [client identifier](/docs/auth/identified-clients) for the member. | String |
+| clientId | The [client identifier](/docs/platform/auth/identified-clients) for the member. | String |
 | connectionId | The unique identifier of the member's [connection](/docs/connect). | String |
 | isConnected | Whether the member is connected to Ably or not. | Boolean |
 | profileData | The optional [profile data](#profile-data) associated with the member. | Object |
diff --git a/src/pages/docs/spaces/cursors.mdx b/src/pages/docs/spaces/cursors.mdx
index 2b3e30f231..84670d55fd 100644
--- a/src/pages/docs/spaces/cursors.mdx
+++ b/src/pages/docs/spaces/cursors.mdx
@@ -90,7 +90,7 @@ The following are the properties of a cursor event payload:
 | Property | Description | Type |
 | -------- | ----------- | ---- |
 | connectionId | The unique identifier of the member's [connection](/docs/connect). | String |
-| clientId | The [client identifier](/docs/auth/identified-clients) for the member. | String |
+| clientId | The [client identifier](/docs/platform/auth/identified-clients) for the member. | String |
 | position | An object containing the position of a member's cursor. | Object |
 | position.x | The position of the member's cursor on the X-axis. | Number |
 | position.y | The position of the member's cursor on the Y-axis. | Number |
diff --git a/src/pages/docs/spaces/index.mdx b/src/pages/docs/spaces/index.mdx
index 6c4392dc7d..e6ace7342b 100644
--- a/src/pages/docs/spaces/index.mdx
+++ b/src/pages/docs/spaces/index.mdx
@@ -31,7 +31,7 @@ Whether you're adding realtime collaborative capabilities to an existing applica
 
 There are several benefits provided by the fact that the Spaces SDK is built on top of the Ably JavaScript SDK:
 
-* [Authentication](/docs/auth) and [connection management](/docs/connect) are handled by the underlying SDK.
+* [Authentication](/docs/platform/auth) and [connection management](/docs/connect) are handled by the underlying SDK.
 * You can use the Ably JavaScript SDK to extend your application's functionality further with [Pub/Sub](/docs/basics).
 
 The following are a selection of additional features that can be built using Ably Pub/Sub to further enhance your collaborative applications:
diff --git a/src/pages/docs/spaces/locations.mdx b/src/pages/docs/spaces/locations.mdx
index e55ff8af5a..0824d462b3 100644
--- a/src/pages/docs/spaces/locations.mdx
+++ b/src/pages/docs/spaces/locations.mdx
@@ -81,7 +81,7 @@ The following are the properties of a location event payload:
 
 | Property | Description | Type |
 | -------- | ----------- | ---- |
-| member.clientId| The [client identifier](/docs/auth/identified-clients) for the member. | String |
+| member.clientId| The [client identifier](/docs/platform/auth/identified-clients) for the member. | String |
 | member.connectionId| The unique identifier of the member's [connection](/docs/connect). | String |
 | member.isConnected | Whether the member is connected to Ably or not.| Boolean |
 | member.lastEvent.name| The most recent event emitted by the member. Will be one of `enter`, `update`, `present`, or `leave`. | String |
diff --git a/src/pages/docs/spaces/locking.mdx b/src/pages/docs/spaces/locking.mdx
index 3f88a6c094..b0d0004734 100644
--- a/src/pages/docs/spaces/locking.mdx
+++ b/src/pages/docs/spaces/locking.mdx
@@ -154,7 +154,7 @@ The following are the properties of a lock event payload:
 | timestamp| The timestamp of the lock event. | Number |
 | attributes | The optional attributes of the lock, such as the ID of the component it relates to. | Object |
 | reason | If set, gives the reason for `status`. Successful lock requests do not set a `reason`. | ErrorInfo |
-| member.clientId| The [client identifier](/docs/auth/identified-clients) for the member. | String |
+| member.clientId| The [client identifier](/docs/platform/auth/identified-clients) for the member. | String |
 | member.connectionId| The unique identifier of the member's [connection](/docs/connect). | String |
 | member.isConnected | Whether the member is connected to Ably or not. | Boolean |
 | member.lastEvent.name| The most recent event emitted by the member. Will be one of `enter`, `update`, `present`, or `leave`. | String |
diff --git a/src/pages/docs/spaces/react.mdx b/src/pages/docs/spaces/react.mdx
index d6e61821bd..b845d3553c 100644
--- a/src/pages/docs/spaces/react.mdx
+++ b/src/pages/docs/spaces/react.mdx
@@ -41,12 +41,12 @@ React version 16.8.0 or above is required.
 
 ## Authenticate <a id="authenticate"/>
 
-An [API key](/docs/auth#api-keys) is required to authenticate with Ably. API keys are used either to authenticate directly with Ably using [basic authentication](/docs/auth/basic), or to generate tokens for untrusted clients using [token authentication](/docs/auth/token).
+An [API key](/docs/platform/auth#api-keys) is required to authenticate with Ably. API keys are used either to authenticate directly with Ably using [basic authentication](/docs/platform/auth/basic), or to generate tokens for untrusted clients using [token authentication](/docs/platform/auth/token).
 
 [Sign up](https://ably.com/sign-up) to Ably to create an API key in the [dashboard](https://ably.com/dashboard) or use the [Control API](/docs/platform/account/control-api) to create an API programmatically.
 
 <Aside data-type='important'>
-The examples use [basic authentication](/docs/auth/basic) to demonstrate usage for convenience. In your own applications, basic authentication should never be used on the client-side as it exposes your Ably API key. Instead use [token authentication](/docs/auth/token).
+The examples use [basic authentication](/docs/platform/auth/basic) to demonstrate usage for convenience. In your own applications, basic authentication should never be used on the client-side as it exposes your Ably API key. Instead use [token authentication](/docs/platform/auth/token).
 </Aside>
 
 ## Usage <a id="usage"/>
diff --git a/src/pages/docs/spaces/setup.mdx b/src/pages/docs/spaces/setup.mdx
index b421bc5f9a..52a9e48df3 100644
--- a/src/pages/docs/spaces/setup.mdx
+++ b/src/pages/docs/spaces/setup.mdx
@@ -8,17 +8,17 @@ Use these instructions to install, authenticate and instantiate the Spaces SDK.
 ## Authenticate <a id="authenticate"/>
 
 <Aside data-type='important'>
-Client-side applications must use [token authentication](/docs/auth/token). API keys should never be exposed in client-side code because they don't expire and cannot be scoped to specific users.
+Client-side applications must use [token authentication](/docs/platform/auth/token). API keys should never be exposed in client-side code because they don't expire and cannot be scoped to specific users.
 </Aside>
 
 Spaces requires an authenticated client with a `clientId` to identify users. The recommended approach is:
 
-1. **Client-side apps** (browsers, mobile apps): Use [JWT authentication](/docs/auth/token/jwt) with `authCallback` to fetch JWTs from your server
+1. **Client-side apps** (browsers, mobile apps): Use [JWT authentication](/docs/platform/auth/token/jwt) with `authCallback` to fetch JWTs from your server
 2. **Server-side apps** (Node.js, Python, etc.): Use your API key directly
 
 [Sign up](https://ably.com/sign-up) to Ably to create an API key in the [dashboard](https://ably.com/dashboard) or use the [Control API](/docs/platform/account/control-api) to create an API programmatically. Your server will use this key to issue tokens to clients.
 
-API keys and tokens have a set of capabilities assigned to them that specify which operations, such as `subscribe` or `publish` can be performed on which resources. To use the Spaces SDK, the API key requires the following [capabilities](/docs/auth/capabilities):
+API keys and tokens have a set of capabilities assigned to them that specify which operations, such as `subscribe` or `publish` can be performed on which resources. To use the Spaces SDK, the API key requires the following [capabilities](/docs/platform/auth/capabilities):
 
 * Publish
 * Subscribe
@@ -119,7 +119,7 @@ const spaces = new Spaces(client);
 ```
 </Code>
 
-Your auth server endpoint (`/api/ably-token`) should authenticate the user and return a token with the user's `clientId`. See the [token authentication](/docs/auth/token) documentation for server implementation examples.
+Your auth server endpoint (`/api/ably-token`) should authenticate the user and return a token with the user's `clientId`. See the [token authentication](/docs/platform/auth/token) documentation for server implementation examples.
 
 ### Server-side authentication <a id="server-side-auth"/>
 
@@ -137,7 +137,7 @@ const spaces = new Spaces(client);
 ```
 </Code>
 
-A [`ClientOptions`](/docs/api/realtime-sdk#client-options) object may be passed to the Ably JavaScript SDK to further customize the connection. When using token authentication, the `clientId` is set by your auth server. When using API key authentication server-side, you must provide a `clientId` so that the client is [identified](/docs/auth/identified-clients).
+A [`ClientOptions`](/docs/api/realtime-sdk#client-options) object may be passed to the Ably JavaScript SDK to further customize the connection. When using token authentication, the `clientId` is set by your auth server. When using API key authentication server-side, you must provide a `clientId` so that the client is [identified](/docs/platform/auth/identified-clients).
 
 ### Using Ably JWT (alternative) <a id="jwt-auth"/>
 
@@ -195,10 +195,10 @@ const spaces = new Spaces(client);
 **Why choose JWT for Spaces?**
 - No Ably SDK required on your server
 - Integrates with existing Auth0/Firebase/Cognito flows
-- Supports [channel-scoped claims](/docs/auth/capabilities#custom-restrictions) for user metadata
+- Supports [channel-scoped claims](/docs/platform/auth/capabilities#custom-restrictions) for user metadata
 - Eliminates client round-trip to Ably
 
-See [Token authentication](/docs/auth/token#choosing) for detailed guidance on when to use JWT vs Ably Tokens.
+See [Token authentication](/docs/platform/auth/token#choosing) for detailed guidance on when to use JWT vs Ably Tokens.
 
 <Aside data-type='note'>
 Only the promises version of the Ably JavaScript is supported when using Spaces, not the callback version.
diff --git a/src/pages/docs/spaces/space.mdx b/src/pages/docs/spaces/space.mdx
index f794c9602e..58f3ada66e 100644
--- a/src/pages/docs/spaces/space.mdx
+++ b/src/pages/docs/spaces/space.mdx
@@ -187,7 +187,7 @@ The following are the properties of an individual `member` within a space event
 
 | Property | Description | Type |
 | -------- | ----------- | ---- |
-| clientId | The [client identifier](/docs/auth/identified-clients) for the member. | String |
+| clientId | The [client identifier](/docs/platform/auth/identified-clients) for the member. | String |
 | connectionId | The unique identifier of the member's [connection](/docs/connect). | String |
 | isConnected | Whether the member is connected to Ably or not. | Boolean |
 | profileData | The optional [profile data](#profile-data) associated with the member. | Object |

From 60628d8a1e43e07f2da103eb1a5397e98be9bb46 Mon Sep 17 00:00:00 2001
From: umair <umair.hussain@ably.com>
Date: Fri, 6 Mar 2026 09:32:46 +0000
Subject: [PATCH 3/3] adds a specific pubsub auth page matching Chat and Spaces

---
 src/data/nav/pubsub.ts            |   4 +
 src/pages/docs/authentication.mdx | 411 ++++++++++++++++++++++++++++++
 2 files changed, 415 insertions(+)
 create mode 100644 src/pages/docs/authentication.mdx

diff --git a/src/data/nav/pubsub.ts b/src/data/nav/pubsub.ts
index 7285937af7..78a5288ba4 100644
--- a/src/data/nav/pubsub.ts
+++ b/src/data/nav/pubsub.ts
@@ -83,6 +83,10 @@ export default {
         },
       ],
     },
+    {
+      name: 'Authentication',
+      link: '/docs/authentication',
+    },
     {
       name: 'Connections',
       pages: [
diff --git a/src/pages/docs/authentication.mdx b/src/pages/docs/authentication.mdx
new file mode 100644
index 0000000000..84c3d83e16
--- /dev/null
+++ b/src/pages/docs/authentication.mdx
@@ -0,0 +1,411 @@
+---
+title: Pub/Sub authentication
+meta_description: "Configure authentication for Pub/Sub applications with the required capabilities."
+meta_keywords: "authentication, pub/sub, capabilities, JWT, token"
+---
+
+All Pub/Sub clients must authenticate with Ably before they can publish or subscribe to channels. Use [token authentication](/docs/platform/auth/token) for client-side applications, and [basic authentication](/docs/platform/auth/basic) for trusted server environments.
+
+## Authentication flow
+
+The recommended authentication flow for client-side applications is:
+
+1. Your auth server authenticates the user.
+2. Your auth server issues an Ably-compatible token (JWT format is recommended for most apps).
+3. The client SDK fetches tokens with `authCallback` and refreshes them automatically before expiry.
+
+<Aside data-type='important'>
+Never use API keys in client-side code. API keys do not expire and are not suitable for untrusted clients.
+</Aside>
+
+## Server setup
+
+Create an endpoint that validates user-provided credentials and returns JWTs with the appropriate capabilities:
+
+<Code>
+```javascript
+// Server-side JWT with channel-scoped capabilities
+import jwt from 'jsonwebtoken';
+
+const [keyName, keySecret] = process.env.ABLY_API_KEY.split(':');
+
+const ablyJwt = jwt.sign(
+  {
+    'x-ably-capability': JSON.stringify({
+      'your-channel': ['publish', 'subscribe', 'presence', 'history'],
+    }),
+    'x-ably-clientId': userId,
+  },
+  keySecret,
+  { algorithm: 'HS256', keyid: keyName, expiresIn: '1h' }
+);
+```
+
+```python
+# Server-side JWT with channel-scoped capabilities
+import jwt
+import json
+import time
+import os
+
+key_name, key_secret = os.environ['ABLY_API_KEY'].split(':')
+
+now = int(time.time())
+ably_jwt = jwt.encode(
+    {
+        'iat': now,
+        'exp': now + 3600,
+        'x-ably-capability': json.dumps({
+            'your-channel': ['publish', 'subscribe', 'presence', 'history'],
+        }),
+        'x-ably-clientId': user_id,
+    },
+    key_secret,
+    algorithm='HS256',
+    headers={'kid': key_name}
+)
+```
+
+```go
+// Server-side JWT with channel-scoped capabilities
+header := map[string]string{
+    "typ": "JWT",
+    "alg": "HS256",
+    "kid": keyName,
+}
+
+currentTime := time.Now().Unix()
+claims := map[string]interface{}{
+    "iat":                currentTime,
+    "exp":                currentTime + 3600,
+    "x-ably-capability":  `{"your-channel":["publish","subscribe","presence","history"]}`,
+    "x-ably-clientId":    userId,
+}
+
+// Sign using HS256 with your API key secret
+```
+
+```ruby
+# Server-side JWT with channel-scoped capabilities
+require 'jwt'
+
+key_name, key_secret = ENV['ABLY_API_KEY'].split(':')
+
+now = Time.now.to_i
+payload = {
+  'iat' => now,
+  'exp' => now + 3600,
+  'x-ably-capability' => '{"your-channel":["publish","subscribe","presence","history"]}',
+  'x-ably-clientId' => user_id
+}
+
+ably_jwt = JWT.encode(payload, key_secret, 'HS256', { 'kid' => key_name })
+```
+
+```php
+// Server-side JWT with channel-scoped capabilities
+$header = [
+    'typ' => 'JWT',
+    'alg' => 'HS256',
+    'kid' => $keyName
+];
+$currentTime = time();
+$claims = [
+    'iat' => $currentTime,
+    'exp' => $currentTime + 3600,
+    'x-ably-capability' => '{"your-channel":["publish","subscribe","presence","history"]}',
+    'x-ably-clientId' => $userId
+];
+$base64Header = base64_encode(json_encode($header));
+$base64Claims = base64_encode(json_encode($claims));
+$signature = hash_hmac('sha256', $base64Header . '.' . $base64Claims, $keySecret, true);
+$jwt = $base64Header . '.' . $base64Claims . '.' . base64_encode($signature);
+```
+
+```java
+Map<String, Object> headerClaims = new HashMap<>();
+headerClaims.put("typ", "JWT");
+headerClaims.put("alg", "HS256");
+headerClaims.put("kid", keyName);
+
+long currentTimeInSeconds = System.currentTimeMillis() / 1000;
+
+Map<String, Object> claims = new HashMap<>();
+claims.put("iat", currentTimeInSeconds);
+claims.put("exp", currentTimeInSeconds + 3600);
+claims.put("x-ably-capability", "{\"your-channel\":[\"publish\",\"subscribe\",\"presence\",\"history\"]}");
+claims.put("x-ably-clientId", userId);
+
+Algorithm algorithm = Algorithm.HMAC256(keySecret);
+String token = JWT.create()
+        .withHeader(headerClaims)
+        .withPayload(claims)
+        .sign(algorithm);
+```
+
+```csharp
+// Server-side JWT with channel-scoped capabilities
+var header = new Dictionary<string, object>
+{
+    { "typ", "JWT" },
+    { "alg", "HS256" },
+    { "kid", keyName }
+};
+
+var currentTime = DateTimeOffset.UtcNow.ToUnixTimeSeconds();
+var claims = new Dictionary<string, object>
+{
+    { "iat", currentTime },
+    { "exp", currentTime + 3600 },
+    { "x-ably-capability", "{\"your-channel\":[\"publish\",\"subscribe\",\"presence\",\"history\"]}" },
+    { "x-ably-clientId", userId }
+};
+
+// Sign using HS256 with your API key secret
+```
+</Code>
+
+## Client setup
+
+Use `authCallback` to fetch tokens from your auth server. The SDK handles token refresh automatically:
+
+<Code>
+```javascript
+import * as Ably from 'ably';
+
+const realtime = new Ably.Realtime({
+  authCallback: async (tokenParams, callback) => {
+    try {
+      const response = await fetch('/api/ably-token', { credentials: 'include' });
+      if (!response.ok) throw new Error('Auth failed');
+      const jwt = await response.text();
+      callback(null, jwt);
+    } catch (error) {
+      callback(error, null);
+    }
+  },
+});
+```
+
+```react
+import { useMemo } from 'react';
+import * as Ably from 'ably';
+import { AblyProvider } from 'ably/react';
+
+export function App() {
+  const client = useMemo(
+    () =>
+      new Ably.Realtime({
+        authCallback: async (tokenParams, callback) => {
+          try {
+            const response = await fetch('/api/ably-token', { credentials: 'include' });
+            if (!response.ok) throw new Error('Auth failed');
+            callback(null, await response.text());
+          } catch (error) {
+            callback(error, null);
+          }
+        },
+      }),
+    []
+  );
+
+  return (
+    <AblyProvider client={client}>
+      <YourApp />
+    </AblyProvider>
+  );
+}
+```
+
+```python
+from ably import AblyRealtime
+
+async def auth_callback(token_params):
+    # Fetch JWT from your auth server
+    return await fetch_ably_jwt()
+
+realtime = AblyRealtime(auth_callback=auth_callback)
+```
+
+```swift
+import Ably
+
+let options = ARTClientOptions()
+options.authCallback = { tokenParams, callback in
+    fetchAblyJwt { result in
+        switch result {
+        case .success(let jwt):
+            callback(jwt as ARTTokenDetailsCompatible, nil)
+        case .failure(let error):
+            callback(nil, error)
+        }
+    }
+}
+
+let realtime = ARTRealtime(options: options)
+```
+
+```kotlin
+import io.ably.lib.realtime.AblyRealtime
+import io.ably.lib.rest.Auth
+import io.ably.lib.types.ClientOptions
+
+val realtime = AblyRealtime(
+    ClientOptions().apply {
+        authCallback = Auth.TokenCallback { _ ->
+            // Return JWT string from your auth server
+            fetchAblyJwt()
+        }
+    }
+)
+```
+
+```java
+import io.ably.lib.realtime.AblyRealtime;
+import io.ably.lib.rest.Auth;
+import io.ably.lib.types.ClientOptions;
+
+ClientOptions options = new ClientOptions();
+options.authCallback = tokenParams -> {
+    // Return JWT string from your auth server
+    return fetchAblyJwt();
+};
+
+AblyRealtime realtime = new AblyRealtime(options);
+```
+
+```csharp
+using IO.Ably;
+using IO.Ably.Realtime;
+
+var options = new ClientOptions
+{
+    AuthCallback = async tokenParams =>
+    {
+        // Fetch JWT from your auth server
+        return await FetchAblyJwtAsync();
+    }
+};
+
+var realtime = new AblyRealtime(options);
+```
+
+```flutter
+import 'package:ably_flutter/ably_flutter.dart' as ably;
+
+final options = ably.ClientOptions()
+  ..authCallback = (tokenParams) async {
+    // Fetch JWT from your auth server
+    return await fetchAblyJwt();
+  };
+
+final realtime = ably.Realtime(options: options);
+```
+
+```ruby
+require 'ably'
+
+realtime = Ably::Realtime.new(auth_callback: ->(token_params) {
+  # Fetch JWT from your auth server
+  fetch_ably_jwt
+})
+```
+
+```go
+package main
+
+import "github.com/ably/ably-go/ably"
+
+client, err := ably.NewRealtime(
+    ably.WithAuthCallback(func(ctx context.Context, params ably.TokenParams) (ably.Tokener, error) {
+        // Fetch JWT from your auth server
+        return ably.TokenString(fetchAblyJwt()), nil
+    }),
+)
+```
+
+```objc
+#import "AblyRealtime.h"
+
+ARTClientOptions *options = [[ARTClientOptions alloc] init];
+options.authCallback = ^(ARTTokenParams *tokenParams, void (^callback)(id<ARTTokenDetailsCompatible>, NSError *)) {
+    [self fetchAblyJwtWithCompletion:^(NSString *jwt, NSError *error) {
+        if (error) {
+            callback(nil, error);
+        } else {
+            callback(jwt, nil);
+        }
+    }];
+};
+
+ARTRealtime *realtime = [[ARTRealtime alloc] initWithOptions:options];
+```
+
+```php
+require 'vendor/autoload.php';
+
+use Ably\AblyRest;
+
+$ably = new AblyRest([
+    'authCallback' => function ($tokenParams) {
+        // Fetch JWT from your auth server
+        return fetchAblyJwt();
+    },
+]);
+```
+</Code>
+
+## Pub/Sub capabilities
+
+Capabilities are permissions that control what operations a client can perform. When you create a token, you specify which capabilities the client has:
+
+| Capability | Description |
+|------------|-------------|
+| `publish` | Publish messages to channels |
+| `subscribe` | Subscribe to messages, presence state changes, and annotations on channels |
+| `presence` | Register presence on a channel (enter, update, and leave) |
+| `history` | Retrieve message and presence history on channels |
+| `annotation-publish` | Publish [annotations](/docs/messages/annotations) to messages on a channel |
+| `annotation-subscribe` | Subscribe to individual [annotations](/docs/messages/annotations) on a channel |
+| `message-update-own` | [Update messages](/docs/messages/updates-deletes) where the original publisher's `clientId` matches the updater's `clientId` |
+| `message-update-any` | [Update any message](/docs/messages/updates-deletes) on the channel |
+| `message-delete-own` | [Delete messages](/docs/messages/updates-deletes) where the original publisher's `clientId` matches the deleter's `clientId` |
+| `message-delete-any` | [Delete any message](/docs/messages/updates-deletes) on the channel |
+| `channel-metadata` | Get metadata for a channel and enumerate channels |
+| `push-subscribe` | Subscribe devices for push notifications on channels |
+| `push-admin` | Manage device registrations and push subscriptions for all devices in an app |
+| `privileged-headers` | Set data in the privileged section of [message extras](/docs/api/realtime-sdk/messages#extras) |
+
+## Channel-scoped capabilities
+
+You can scope capabilities to specific channels, a namespace of channels, or all channels:
+
+* `my-channel` - a specific channel
+* `my-namespace:*` - all channels in the `my-namespace:` namespace
+* `*` - all channels
+
+For example, to grant different permissions on different channels:
+
+<Code>
+```javascript
+'x-ably-capability': JSON.stringify({
+  'public:*': ['subscribe'],
+  'private:user-123': ['publish', 'subscribe', 'presence'],
+})
+```
+</Code>
+
+## Token lifecycle and permission updates
+
+- With `authCallback` or `authUrl`, token refresh is automatic and handled by the SDK.
+- To change a user's capabilities during an active session, issue a new token from your auth server and re-authenticate:
+
+<Code>
+```javascript
+// Re-authenticate to pick up updated capabilities
+await realtime.auth.authorize();
+```
+</Code>
+
+- To immediately remove access, [revoke issued tokens](/docs/platform/auth/revocation).
+- If your capability JSON is too large for JWT or must remain confidential, use native [Ably Tokens](/docs/platform/auth/token/ably-tokens).