*the maximum number of clients that can be simultaneously present on a channel when server-side batching is enabled*
| 200 | 5,000 | 10,000 | 20,000 | | **Objects per channel***the maximum number of objects that can be stored on a channel*
| 100 | 100 | 100 | 100 | + +## Client identifier limits + +There is no limit to the length of a `clientId`, however, the clientId is counted as part of the message size and will contribute towards the total message size limits for your package. + +## Channel identifier limits + +There is no strict limit to the length of channel names. Channel names must comply with the [channel naming restrictions](/docs/channels#use) regarding allowed characters and format. + ## Connection limits Connection limits relate to the realtime [connections](/docs/connect) made to Ably from your account. From 7b768d7556b01ee704862840b8a4072702fed2d3 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Thu, 11 Sep 2025 08:44:26 +0200 Subject: [PATCH 04/11] How can I subscribe to messages using REST only SDKs? --- src/pages/docs/basics/index.mdx | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/pages/docs/basics/index.mdx b/src/pages/docs/basics/index.mdx index 1b10b522ff..e9dae6a6b2 100644 --- a/src/pages/docs/basics/index.mdx +++ b/src/pages/docs/basics/index.mdx @@ -65,6 +65,16 @@ The REST interface communicates with Ably using the HTTP protocol and is effecti * issue tokens on behalf of other realtime clients * retrieve persisted messages, presence history and application usage statistics +#### Implementing realtime features with REST-only SDKs + +If you're working with REST-only SDKs or environments where realtime connections aren't available, you can still implement realtime functionality using these alternatives: + +1. **[MQTT protocol adapter](/docs/protocols/mqtt)** - Translates between MQTT and Ably's protocol, ideal for IoT devices and constrained environments +2. **[PubNub protocol adapter](/docs/protocols/pubnub)** - Use existing PubNub SDKs with Ably for easy migration +3. **[Ably queues](/docs/platform/integrations/queues)** - Consume realtime data server-side using AMQP or STOMP protocols + +These solutions enable you to subscribe to and process realtime messages without maintaining persistent connections through Ably SDKs. + ### Realtime interface The realtime interface is implemented using an Ably-defined protocol, primarily over WebSockets. It enables clients to establish and maintain a persistent connection to Ably. The realtime interface extends the functionality of the REST interface and is most commonly used client-side. It is used to: From ad82abf20bb197e5cc6358ab61f3603b342c6904 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Thu, 11 Sep 2025 08:50:07 +0200 Subject: [PATCH 05/11] CSP Rejection to internet-up.ably-realtime.com/is-the-internet-up.txt --- src/pages/docs/platform/errors/codes.mdx | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/pages/docs/platform/errors/codes.mdx b/src/pages/docs/platform/errors/codes.mdx index d820806a99..3bde65a0fa 100644 --- a/src/pages/docs/platform/errors/codes.mdx +++ b/src/pages/docs/platform/errors/codes.mdx @@ -599,6 +599,16 @@ The request will be automatically retried by the SDK. **Resolution:** If the client never connects to the [primary or fallback endpoints](https://faqs.ably.com/routing-around-network-and-dns-issues), check any firewall rules that may be blocking access to Ably's [endpoints](https://faqs.ably.com/if-i-need-to-whitelist-ablys-servers-from-a-firewall-which-ports-ips-and/or-domains-should-i-add). +**Network connectivity detection:** Ably SDKs use `https://internet-up.ably-realtime.com/is-the-internet-up.txt` to test network connectivity when connection attempts fail. If CSP policies block this endpoint, ensure your Content Security Policy includes: + +
+```
+Content-Security-Policy: connect-src https://internet-up.ably-realtime.com; script-src https://internet-up.ably-realtime.com
+```
+
+
+Blocking this resource causes clients to assume they're offline and prevents fallback host usage.
+
## 80016: Operation on superseded connection
This error occurs when a browser [connection](/docs/connect/states#connection-states) upgrades from an HTTP (Comet) transport to WebSockets. It is logged by the client library when operations are performed on the older transport.
From 93730918f378aa06e52637b308daf1cea54292d8 Mon Sep 17 00:00:00 2001
From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com>
Date: Thu, 11 Sep 2025 08:59:34 +0200
Subject: [PATCH 06/11] Are the Message and Data Transfer Limits Enforced
Separately?
---
src/pages/docs/platform/pricing/limits.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/pages/docs/platform/pricing/limits.mdx b/src/pages/docs/platform/pricing/limits.mdx
index 0ce19741a6..dcf81f3f42 100644
--- a/src/pages/docs/platform/pricing/limits.mdx
+++ b/src/pages/docs/platform/pricing/limits.mdx
@@ -60,7 +60,7 @@ Application limits relate to the quantity of resources that can be created per a
## Message limits
-Message limits relate to the number, rate and bandwidth of messages consumed across you account.
+Message limits relate to the number, rate and bandwidth of messages consumed across you account. Message count limits and data transfer (bandwidth) limits are enforced separately - exceeding one does not affect the other.
| Message limit | Free | Standard | Pro | Enterprise |
| ------------- | ---- | -------- | --- | ---------- |
From 61165a85169f2b98d0259f0bae7811ee85554b10 Mon Sep 17 00:00:00 2001
From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com>
Date: Thu, 11 Sep 2025 09:10:13 +0200
Subject: [PATCH 07/11] Should I reduce the REST publish timeout?
---
src/pages/docs/pub-sub/index.mdx | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/src/pages/docs/pub-sub/index.mdx b/src/pages/docs/pub-sub/index.mdx
index e7a9eaeae2..d071ffdd28 100644
--- a/src/pages/docs/pub-sub/index.mdx
+++ b/src/pages/docs/pub-sub/index.mdx
@@ -437,6 +437,28 @@ if err := channel.Publish(context.Background(), "example", "message data"); err
```
+### REST publish timeouts
+
+REST publish operations have a default 10-second timeout. While you may consider reducing this timeout for faster failure feedback, be aware that this can create problems:
+
+Short timeouts can be problematic for the following reasons:
+
+- Most requests that exceed short timeouts, for example < 1s, still succeed with normal latency.
+- Retrying typically doesn't speed up message delivery and creates additional system load.
+- During high load or scaling operations, retry storms can worsen performance.
+- You'll miss important error notifications (rate limits, channel limits) if requests timeout prematurely.
+
+The default 10-second timeout is designed to:
+
+- Account for channel activation latency in multi-region deployments.
+- Handle network and processing queue variations.
+- Provide reliable error reporting for legitimate failures.
+
+When to consider timeout adjustments:
+
+- Use `httpOpenTimeout` (default 4s) for connection establishment issues, not `httpRequestTimeout` for the full request.
+- Only reduce request timeouts if you have robust retry logic and can handle increased system load.
+