Deprecation of protocol version 1 - November 2025
SDKs using version 1 of Ably's realtime protocol were sunset on 1st November 2025. If you are using an SDK older than this, please upgrade to a newer one as soon as possible.
This version was superseded by version 2 in January 2023. It introduced new functionality, and allows the use of a more efficient and scalable backend implementation. New features are not available using version 1 of the protocol, nor in any SDKs implementing it.
Affected SDKs
SDK versions up to and including those listed below are now considered deprecated. If you are using one of these versions, upgrade to a supported SDK version.
| Product | Language | Versions |
|---|---|---|
| Pub/Sub | JavaScript | <= 1.2.34 |
| Pub/Sub | Java | <= 1.2.33 |
| Pub/Sub | Swift / Objective-C | <= 1.2.24 |
| Pub/Sub | .NET | <= 1.2.12 |
| Pub/Sub | Go | <= 1.2.14 |
| Pub/Sub | Python | <= 2.0.0-beta.2 |
| Pub/Sub | Ruby | <= 1.2.5 |
| Pub/Sub | PHP | <= 1.1.9 |
| Pub/Sub | Flutter | <= 1.2.26 |
| Kafka Connect | - | <= 4.1.0 |
Contact support if you have any questions.
Deprecation timeline
From 2nd November 2026 or shortly after, protocol v1 clients will operate in a partially degraded state: in particular, resumes will stop working, so that any reconnect after temporary loss of connection will be given a fresh connection.
FAQs
When exactly will my app be switched?
The change will roll out over the course of the week beginning 2nd November 2026. It will be applied region by region, not account by account or app by app. This means it isn't possible to give an exact day and time for a particular account or app.
What changes for protocol v1 clients?
The main change is that resume will no longer work. A client that reconnects after a temporary loss of connection will be given a fresh connection.
There will likely be other minor behaviour changes, but we expect that the lack of resumes will be the largest one.
(What's actually happening is that protocol v1 connections will start to be handled by the same system that handles protocol v2+ connections. That system is unable to do resumes in the same way that protocol v1 handles resumes, and has other small behaviour differences from the legacy system. This is the compromise by which we will be able to continue handling protocol v1 connections for far longer than we had originally planned, while still meeting our security and maintenance requirements.)
Can I request a further extension?
Unfortunately not. This plan is already the extension: the original plan was to stop supporting protocol version 1 entirely by now. Removing support for resume is how we are making it possible for protocol v1 clients to keep working, albeit with reduced functionality, which is better than shuttering them entirely.
Will Ably stop accepting protocol v1 connections in future?
No: due to this compromise, we no longer need to shutter protocol v1 altogether. Once protocol v1 connections are moved onto the same system that handles protocol version 2 and later, Ably can continue to accept them indefinitely.
Which protocol version does a connection get if it doesn't specify one?
Right now, such a connection will get protocol v1. After the change, a connection not specifying a version will be served whatever the latest protocol version is. This only matters if you have written your own custom client against the realtime protocol, and are not requesting a particular protocol version. If you do this and want a stable wire protocol, always specify a v query string parameter.
We do also strongly recommend using an Ably SDK if at all possible. SDKs have many advantages, such as automatic use of cross-region fallbacks in case your local region is having issues. We now have SDKs for more platforms than ever before, such as a new pure Dart implementation.