diff --git a/src/pages/docs/channels/options/deltas.mdx b/src/pages/docs/channels/options/deltas.mdx
index 75bfb30734..1aac702e9a 100644
--- a/src/pages/docs/channels/options/deltas.mdx
+++ b/src/pages/docs/channels/options/deltas.mdx
@@ -33,6 +33,12 @@ There is no constraint on how many publishers or subscribers there are. If there
If a delta is generated and it results in a difference that is not appreciably smaller than the original message, or is larger than the original message, for example if successive messages are completely different, then the delta will not be sent. Clients will receive the original, unprocessed message.
+
+
## Install vcdiff decoder
diff --git a/src/pages/docs/connect/index.mdx b/src/pages/docs/connect/index.mdx
index 5e677d29ad..6cf03fca0f 100644
--- a/src/pages/docs/connect/index.mdx
+++ b/src/pages/docs/connect/index.mdx
@@ -222,6 +222,12 @@ By default, the Ably Pub/Sub JavaScript SDK adds a listener for the `beforeunloa
If a connection to Ably is not explicitly closed when there is a page unload event, then the connection state is preserved by Ably for 2 minutes. Preserving connection state for 2 minutes when there is an unexpectedly dropped connection provides the opportunity for the client to reconnect and resume the connection without losing any messages.
+
+
### Reliability considerations
The `beforeunload` event can be unreliable and is not guaranteed to fire under certain circumstances:
* The event may fire but the page is subsequently not disposed of (navigation can be cancelled).
diff --git a/src/pages/docs/connect/states.mdx b/src/pages/docs/connect/states.mdx
index 60f98e8638..232b4dbb2a 100644
--- a/src/pages/docs/connect/states.mdx
+++ b/src/pages/docs/connect/states.mdx
@@ -15,6 +15,12 @@ An Ably SDK is responsible for managing a connection. This includes:
When an SDK is instantiated it will establish a connection immediately, and if the connection drops at any time it will attempt to re-establish it by making repeated connection attempts every 15 seconds for up to two minutes.
+
+
## Available connection states
The different connection states are:
diff --git a/src/pages/docs/messages/index.mdx b/src/pages/docs/messages/index.mdx
index f148ff6eee..7ec8e79863 100644
--- a/src/pages/docs/messages/index.mdx
+++ b/src/pages/docs/messages/index.mdx
@@ -44,6 +44,12 @@ Ensure a message was successfully published by checking the [history](/docs/stor
Ably does not store per-message delivery logs, nor logs of who is subscribed to a channel at any point in time. This means it is not possible to check which users have received messages retroactively.
+
+
## Message conflation
Use message conflation to ensure that clients only ever receive the most up-to-date message, by removing redundant and outdated messages. Message conflation will aggregate published messages for a set period of time and evaluate all messages against a [conflation key](#routing). All but the latest message for each conflation key value will be discarded, and the resulting message, or messages, will be delivered to subscribers as a single batch once the period of time elapses.
diff --git a/src/pages/docs/metadata-stats/metadata/subscribe.mdx b/src/pages/docs/metadata-stats/metadata/subscribe.mdx
index ea3184f7c7..dfddb17ba8 100644
--- a/src/pages/docs/metadata-stats/metadata/subscribe.mdx
+++ b/src/pages/docs/metadata-stats/metadata/subscribe.mdx
@@ -149,6 +149,12 @@ channel.subscribe("channel.closed", new Channel.MessageListener() {
```
+
+
## Log events
The `[meta]log` and [`[meta]log:push`](/docs/push#Error) metachannels publish events that aren't otherwise available to clients.
diff --git a/src/pages/docs/metadata-stats/stats.mdx b/src/pages/docs/metadata-stats/stats.mdx
index 87df7857cb..73094c0c9e 100644
--- a/src/pages/docs/metadata-stats/stats.mdx
+++ b/src/pages/docs/metadata-stats/stats.mdx
@@ -23,6 +23,12 @@ Statistics are available as:
* [Account statistics](#account) covering all applications in your account
* [App statistics](#app) for each individual application
+
+
## Account statistics
Account statistics aggregate metrics from all applications in your account with additional [account-only metrics](#account-only) relating to peak rates monitored and enforced at an account level.
diff --git a/src/pages/docs/presence-occupancy/presence.mdx b/src/pages/docs/presence-occupancy/presence.mdx
index 4251c2518c..1feec4ad35 100644
--- a/src/pages/docs/presence-occupancy/presence.mdx
+++ b/src/pages/docs/presence-occupancy/presence.mdx
@@ -35,6 +35,12 @@ The following presence events are emitted:
| Update | An already present member has updated their [member data](#member-data). Being notified of member data updates can be useful, for example, it can be used to update the status of a user when they are typing a message |
| Present | When subscribing to presence events on a channel that already has members present, this event is emitted for every member already present on the channel before the subscribe listener was registered |
+
+
### Member data
In addition to the [`clientId`](/docs/api/realtime-sdk#client-id) for members on a channel, it is also possible to include data when entering a channel. Clients can [update](/docs/api/realtime-sdk/presence#update) their data at any point which will be broadcasted to all presence subscribers as an `update` event.
diff --git a/src/pages/docs/protocols/mqtt.mdx b/src/pages/docs/protocols/mqtt.mdx
index 62779c03e9..a5f011fc15 100644
--- a/src/pages/docs/protocols/mqtt.mdx
+++ b/src/pages/docs/protocols/mqtt.mdx
@@ -35,6 +35,12 @@ Our MQTT adapter only supports features supported by both the MQTT protocol and
* Doesn't support any MQTT features that aren't normally supported by Ably, such as `WILL` messages, the `RETAIN` flag or [wildcard channel subscriptions](/docs/channels)
* Doesn't support Ably features that aren't supported by the MQTT protocol, such as presence, history and push notifications, though you can use the Ably REST API in conjunction with the adapter to access features available over REST
+
+
## Configuration
To use the Ably MQTT protocol adapter, you'll need to ensure you correctly configure your MQTT client as follows:
diff --git a/src/pages/docs/protocols/pubnub.mdx b/src/pages/docs/protocols/pubnub.mdx
index 96e0ccc928..33000d1d61 100644
--- a/src/pages/docs/protocols/pubnub.mdx
+++ b/src/pages/docs/protocols/pubnub.mdx
@@ -16,6 +16,12 @@ You can use PuBNub and and an Ably SDK side-by-side as they are interoperable, w
For a detailed comparison of Ably and PubNub features, see [Ably vs PubNub](https://ably.com/compare/ably-vs-pubnub).
+
+
## Migration process
A typical migration from PubNub to Ably follows these steps:
diff --git a/src/pages/docs/protocols/pusher.mdx b/src/pages/docs/protocols/pusher.mdx
index f4661c728f..eab349796c 100644
--- a/src/pages/docs/protocols/pusher.mdx
+++ b/src/pages/docs/protocols/pusher.mdx
@@ -11,6 +11,12 @@ Using an adapter introduces some latency and is slower than using an Ably SDK, h
The Pusher Adapter provides some of the advantages of Ably, such as inter-regional message federation, however others, such as [continuity guarantees](https://ably.com/four-pillars-of-dependability), fallback host support, and [message history](/docs/storage-history/history) are only available when using an Ably SDK. If an [Ably SDK](/docs/sdks) is available in your chosen platform, it is recommended you use that, or plan to transition to it eventually.
+
+
## Supported features
The following Pusher features are supported using the adapter:
diff --git a/src/pages/docs/protocols/sse.mdx b/src/pages/docs/protocols/sse.mdx
index d0df184782..5ad6eacdfc 100644
--- a/src/pages/docs/protocols/sse.mdx
+++ b/src/pages/docs/protocols/sse.mdx
@@ -42,6 +42,12 @@ SSE is an excellent alternative to Ably SDK in memory-limited environments.
If you are streaming LLM responses to users, [AI Transport](/docs/ai-transport) provides purpose-built token streaming with resumable sessions and multi-device continuity, addressing the limitations of HTTP-based streaming.
+
+
## Configuration
The following code sample provides an example of how to use SSE with Ably:
diff --git a/src/pages/docs/pub-sub/advanced.mdx b/src/pages/docs/pub-sub/advanced.mdx
index 0bb1c6ad7a..51a48f6459 100644
--- a/src/pages/docs/pub-sub/advanced.mdx
+++ b/src/pages/docs/pub-sub/advanced.mdx
@@ -388,6 +388,12 @@ Subscribing to events server-side using the pub-sub pattern can be disadvantageo
[Message queues](/docs/platform/integrations/queues) are more appropriate to use in this instance, as multiple worker servers enable Ably to distribute the load of messages received. This ensures that each message is only processed once, by any one of your worker servers.
+
+
### Subscription filters
Subscription filters enable you to subscribe to a channel and only receive messages that satisfy a filter expression.
diff --git a/src/pages/docs/push/index.mdx b/src/pages/docs/push/index.mdx
index 9fbe5b7fe6..149cad093e 100644
--- a/src/pages/docs/push/index.mdx
+++ b/src/pages/docs/push/index.mdx
@@ -17,6 +17,12 @@ redirect_from:
Push notifications notify user devices or browsers regardless of whether an application is open and running. They deliver information, such as app updates, social media alerts, or promotional offers, directly to the user's screen. Ably sends push notifications to devices using [Firebase Cloud Messaging](https://firebase.google.com/docs/cloud-messaging) or [Apple Push Notification Service](https://developer.apple.com/notifications/), and to browsers using [Web Push](https://developer.mozilla.org/en-US/docs/Web/API/Push_API). Push notifications don't require a device or browser to stay connected to Ably. Instead, a device's or browser's operating system or web browser maintains its own battery-efficient transport to receive notifications.
+
+
You can publish push notifications to user devices or browsers [directly](/docs/push/publish/#direct-publishing) or [via channels](#via-channels).
Publishing directly sends push notifications to specific devices or browsers identified by unique identifiers, such as a `deviceId` or a `clientId`. This approach is akin to sending a personal message or alerts directly to an individual user's device or browser, bypassing the need for channel subscriptions. It excels in targeted and personalized communications, such as alerts specific to a user's actions, account notifications, or customized updates.
@@ -37,7 +43,7 @@ The following diagram demonstrates the push notification process:
### Configure
-Configuring push notifications sets your [device's](/docs/push/configure/device) or [browser's](/docs/push/configure/web) push notification service to operate with the Ably [platform](https://ably.com/docs/). This process includes inputting the necessary credentials into your Ably [dashboard](https://ably.com/accounts).
+Configuring push notifications sets your [device's](/docs/push/configure/device) or [browser's](/docs/push/configure/web) push notification service to operate with the Ably [platform](/docs/). This process includes inputting the necessary credentials into your Ably [dashboard](https://ably.com/accounts).
### Activate
@@ -97,7 +103,7 @@ Each push target device or browser is associated with a unique `deviceId` and au
* 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.
-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.
+The service credential management is handled by the [Ably SDK](/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.
#### Error handling
diff --git a/src/pages/docs/push/publish.mdx b/src/pages/docs/push/publish.mdx
index 2765f08d1b..5e75aac480 100644
--- a/src/pages/docs/push/publish.mdx
+++ b/src/pages/docs/push/publish.mdx
@@ -26,6 +26,12 @@ Publish push notifications directly or via channels:
- **Description:** Messages are sent to multiple devices or browsers through specified channels.
- **Requirement:** Devices or browsers must be [subscribed](#sub-channels) to these channels to receive notifications.
+
+
## Push notification payload structure
Ably adapts message fields for seamless compatibility with each push notification platform:
@@ -130,7 +136,7 @@ The following example shows a background notification:
## Publish directly
-Direct publishing sends push notifications directly to individual devices via the [Ably SDK](https://ably.com/docs/sdks), bypassing the intermediary of channels. This approach delivers personalized or precise notifications customized for individual users. Direct publishing proves beneficial during the transition phase to Ably's platform and when the objective is to engage existing push notification devices.
+Direct publishing sends push notifications directly to individual devices via the [Ably SDK](/docs/sdks), bypassing the intermediary of channels. This approach delivers personalized or precise notifications customized for individual users. Direct publishing proves beneficial during the transition phase to Ably's platform and when the objective is to engage existing push notification devices.
Direct publishing is also available in [batch mode](#via-batch-push-api), enabling you to publish to a large number of devices in one request.
diff --git a/src/pages/docs/storage-history/history.mdx b/src/pages/docs/storage-history/history.mdx
index 4ad96cf087..c49c49cb12 100644
--- a/src/pages/docs/storage-history/history.mdx
+++ b/src/pages/docs/storage-history/history.mdx
@@ -28,6 +28,11 @@ For any application needing complex queries or long-term data persistence, you m
You can also learn more about [connection states](/docs/connect/states) and the broader [platform architecture](/docs/platform/architecture).
+
## History versus rewind
diff --git a/src/pages/docs/storage-history/storage.mdx b/src/pages/docs/storage-history/storage.mdx
index d9b3346f01..cc5b190c34 100644
--- a/src/pages/docs/storage-history/storage.mdx
+++ b/src/pages/docs/storage-history/storage.mdx
@@ -27,6 +27,12 @@ The time that messages will be stored for depends on your account package:
There is a cost associated with storing messages for longer than the minimum time period. [Contact us](https://ably.com/support) to discuss enabling long term storage.
+
+
### Message deletion
Ably does not currently provide an API to delete persisted messages from the history. Once messages are stored with persisted history enabled, they remain for the entire configured storage period. If you need to delete specific messages from history, [contact us](https://ably.com/support) to discuss requirements.