Incoming webhooks are an easy way to publish messages to Ably from a 3rd party integration. You can use the URL from an incoming webhook with Ably to scale messages globally. This is useful for applications that aren’t built to scale or that can’t easily communicate directly to different devices.

For example, you may want to send a message over Ably every time there is an incoming SMS in your Nexmo account. You can set up a Nexmo webhook using the URL from Ably's incoming webhooks menu. You'll be connected and up and running in just a few minutes.

To register an incoming webhook, in your Ably dashboard navigate to the Ably App you want to register an incoming webhook for and head to the Integrations tab (formerly the Reactor tab).

Register an incoming webhook with a friendly name and a channel to which messages posted via webhook will be published. This will generate a URL to use in other systems' webhook which you can paste as the callback URL.

For more info, please check out the docs or get in touch.

State persistence allows clients to persist the last message on the channel beyond typical Rewind and History API retention periods. You can now persist the last message on a channel for 365 days. This is beneficial for channels that have either a variance in frequency or low frequency of messages. For example, a typical use case would be a dashboard showing a market or currency rate data - the software will have the last data to show immediately after subscribing to a channel, before any new updates occur.

To enable state persistence on a channel, please enable Persist last message on Channel rules to store the last published message for 365 days. Retrieving the last message can be achieved using rewind=1 on the rewind API.

If you have questions about state persistence, please get in touch.

Today, we’re pleased to support Flutter’s growing community of builders by releasing Ably’s Flutter plugin v1.0. This makes it easy for developers to add WebSocket-based pub/sub messaging to their Flutter applications.

Flutter has grown incredibly over the past few years, providing a platform to build modern applications. Increasingly, developers are looking to build event-driven applications where user interactions play out in realtime. That’s where Ably’s Flutter plugin comes in.

The Ably Flutter plugin brings realtime magic to the much loved Flutter ecosystem. If you are new to Ably, here's a quick summary of what we do:

• We provide a scalable, pub/sub messaging infrastructure that you can use on any platform and with any programming language (Seriously, there are work-arounds for any SDKs or platforms that we don't yet directly support).
• While Ably primarily operates over WebSockets, you have the flexibility of choosing between WebSockets, MQTT or Server-Sent Events (SSE) based on the best-suited conditions for the platform on which you intend to run your app.
• Our pub/sub messaging service comes pre-engineered with a full suite of additional features like message-ordering, guaranteed delivery, webhook powered integrations with third-party apps and platforms, and many more. We provide everything you need for any realtime application.

The Ably Flutter plugin is a wrapper around our fully-featured Cocoa and Java client library SDKs, providing iOS and Android support for those using Flutter and Dart.

The plugin is fully open-sourced and is still a work in progress. While it already supports the major Ably functionality, i.e. Pub/Sub messaging, other features like Presence - which is useful to find out the online/ connection status of a client, and Message History - which is useful to retrieve historical messages up to a certain point in time, are soon to come.

Read more in the announcement blog post.

Specifying a rewind parameter will now retrieve the requested number of Messages, and not (as it used to be) that number of things sent on the channel whether those things are Messages or Presence updates.

Since a realtime channel does a full presence sync immediately after attaching, so every presence member in the channel will be retrieved, there's no real usecase for having rewind also give you recent Presence messages — they just partially-duplicated the presence sync. The old behavior meant that on a channel with heavy presence activity, you would appear to get fewer Messages than you expect. For example, if of the last 100 things sent on the channel, 98 were Presence updates and 2 were Messages, then if you did {rewind: '100'} and added a Message listener with channel.subscribe(listener), only two messages would have been delivered to that listener. Users were naturally confused: they requested 100 but only got 2. The new behavior behavior fixes this; you will now get 100 messages, as you would intuitively expect.

We are pleased to announce that Single sign-on (SSO) is now available for all Enterprise customers.

SSO provides more security and ease-of-use for your employees as they no longer need an Ably password and access can be controlled centrally using your organization's IdP (e.g. Okta or Centrify)

How does it work?

Single sign-on (SSO) allows you to sign in to the Ably dashboard using a single credential and sign in flow managed by your organization.

We’ve implemented SSO for the Ably dashboard using SAML. SAML is a protocol most typically used to address web browser SSO use-cases.

Currently we have support for IdP- and SP-initiated flows, including JIT user creation, and strict mode to enforce SSO for your Ably accounts.

How do I try it?

SSO is currently only available for enterprise. Please contact your account manager if you would like it activated. Once activated please follow the setup instructions.

If you're not on an enterprise account but SSO is important to you, please let us know.

How can I provide feedback?

Please visit the Ably portal where you can tell us what you think of SSO, and other features. Alternatively contact us.

Two-factor authentication (2FA) adds an additional layer of security to your account by requiring more than just a password to log in.

Good news: it's now available for you to try as part of our Early Access program 🎉

How does it work?

Once a user has enabled 2FA, when they log in with a password they will also be sent an SMS with a security code that must be input.

Account owners can also force all users who access their account to have 2FA enabled.

📝 Please note: 2FA is only relevant for those using passwords to log in, so excludes Google, Twitter, GitHub and SAML based authentication.

How do I try it?

Navigate to My Settings in your Ably dashboard, click on the Enable two-factor authentication button, and follow the instructions.

Based on feedback we will consider adding additional 2FA functionality, such as TOTP (e.g. Google Authenticator) and push notifications.

How can I provide feedback?

Please visit the Ably portal where you can tell us what you think of this, and other features. Alternatively contact us.

What is the Early Access program?

The Early Access program is about getting new features into our customer's hands as quickly as possible so that we can use their feedback to help build a better product. ⚠️While all our software is thoroughly tested, early access features haven’t yet had a thorough shakedown so there is a greater chance you will discover bugs. The way certain features work may even change before they are released

Fixed bugs:

Address impact of change to interface on extras field on Message #580

Merged pull requests:

Support outbound message extras #581 (QuintinWillison)

Full release notes and changelog on GitHub.

Message Delta Compression reduces the bandwidth required to transmit realtime messages by sending only the changes from the previous message to subscribers each time there’s an update, instead of the entire message.

Let’s say the first message sent over a channel is 16KiB and the message after that is the same but with an additional 4KiB of new data. With Delta Compression that message will have a payload of only 4KiB instead of 20KiB.

This reduces bandwidth costs, improves latencies for end-users, and simplifies development by taking care of message size optimization.

Message Delta Compression is a stable feature: we expect it to be forwards-compatible with future Ably updates.

Using Message Delta Compression with an Ably Client Library SDK

When we released Channel Rewind we introduced channel parameters, expressed as a query string in the connection request or channel name itself. This was a first step to specifying parameters on a per channel basis.

With Ably’s 1.2 Client Library SDKs, available today, there’s now a proper ChannelOptions interface to express channel parameters, of which there are three:

• delta to enable Message Delta Compression
• rewind to enable and specify Ably’s existing Rewind functionality
• cipherParams to manage encryption on a channel

The libraries available in this 1.2 release are:

• JavaScript
• Java
• Cocoa
• .NET

Check our Client Library SDK feature support matrix for full feature coverage across all Client Library SDKs.

A note on ably-js

We're aware of Ably’s JavaScript Client Library SDK footprint and we're actively avoiding bloat. As such we’ve split out the VCDIFF decoder from the core of ably-js. In order to use Delta Compression with ably-js you need to plug in a separate VCDIFF decoder library. This is hosted on Ably’s CDN. We will be modularizing this in the future, but right now this is something you will need to consider.

Message Delta Compression using a non-Ably library

If you need to use a non-Ably library, say to stream over MQTT, and want to use Delta Compression you’ll need to reconstruct the messages yourself using the deltas. Ably provides a VCDIFF decoder library to decode messages yourself for Java, Cocoa, .NET, and JavaScript. The limitations with this is that you must use channel qualifiers. Read the docs for more.

Get started

• The announcement blog post
• Documentation for Message Delta Compression
• Documentation for ChannelOptions
• Ably's practical guide to diff algorithms and delta file formats

Merged pull requests:

• Add logs to help in troubleshooting RestClient http api calls #162 (gernest)
• Remove unused fields definition on RealtimeClient #161 (gernest)
• add implementation for RTN15b-c spec #159 (gernest)

Full release notes and changelog on GitHub.

Fixed bugs:

• Lib failing to retrying on 5xx if it can't parse the body #154
• Flaky TestAuth_ClientID test #80
• Likely leaking goroutines in multiple places #68

Closed issues:

• Implementing reauthentication before or after token expires #153

Merged pull requests:

• Properly set Error.StatusCode #157 (gernest)
• Use ClientOptions.TLSPort for tls connections #156 (gernest)
• RTN15a: Reconnect after networking error. #152 (tcard)
• Fix goroutine leaks #151 (tcard)
• Remove fmt.Println leftovers. #150 (tcard)
• Don't read from connection on inactive state. #149 (tcard)
• RTN23a: Receive from WebSocket with a timeout. #148 (tcard)

Full changelog and release notes.