Today we’re excited to announce a comprehensive update to our chat SDKs giving you even more control over the chat experience and cutting the time it takes to build full-featured chat into your mobile apps, SaaS products, and websites.
Allow me to reintroduce myself
We’ve found that IP Messaging wasn’t an intuitive product name for many of you. When you came looking for a Twilio chat product, you didn’t find one. Instead you found two “messaging” products. We think the name Programmable Chat does a better job of describing the current product and is a bit easier to grok for someone learning about it for the first time.
- Chat webhooks v2: We have fully revamped Chat webhooks to give you even more feedback and control to customize your chat solution. This includes simplified configuration, in-response command modification for pre-event webhooks, and a new event type: UserUpdate – which includes reachability state changes.
- New convenience methods – We added convenience methods to reduce the time required to build common tasks your applications were performing. We’ve added methods for total and unread message counts as well as total member count to the Channel Object.
- Simplified identity management – The AccessManager helps developers with any use case that requires long lived sessions to automatically refresh expiring tokens and keep endpoints authenticated. But when you’re first getting started it’s one more concept to understand and for many use cases like sales chat on an ecommerce site, you may not need long lived sessions. This is why the AccessManager is no longer required and is now provided separately from the SDK with native implementations for each SDK, which also means you no longer need to use the Twilio Commons library.
- Customized push notifications: Push notification behavior in Chat is now more configurable, giving you greater control over how it behaves for your application. Enable and disable push types, specify the template for the content, and set different sounds for different types of notifications.
New Chat pricing model
We’ve found that the beta pricing that we first introduced for our chat product doesn’t reflect the way customers are using it today and doesn’t map well to our long-term vision for the product. This is why we’re announcing a new pricing model to go into effect in January 2017. Chat’s new pricing model is based on three components actions, read requests, and notifications:
Create, Update, & Delete Actions: Actions are API commands executed through the REST API or from the client SDK. For example, send a message, create a channel, update a user attribute, or delete a member from a channel.
Read requests: Read requests are REST API for retrieving an object. For example, get a list of messages or channels via the REST API . To be clear, this is not a user reading a message and read requests from the SDK are free.
Notifications: Notifications are sent in real time to endpoints based on events. For example, notify users when a messages is sent, a user goes offline, or someone is added to a channel.
Migrating to the new SDKs, REST API, & helper libraries
To start using the new REST API functionality, update to the new API base URL: https://chat.twilio.com/v1. If you’re using one of the Twilio maintained helper libraries to interact with the REST API, you’ll need to use the latest version of that helper library to start using the new features in the REST API.
Earlier this year we introduced the new Twilio Helper Libraries and provided some insights into Twilio’s effort to auto-generate all of our helper libraries, using an in-house framework. The goal was to make the helper-libraries more consistent, enable faster iteration, provides greater consistency across languages, and speed up feature delivery and bug fixes. Our next generation PHP & Java helper libraries are Generally Available. If you’re using older versions of our Java or PHP helper libraries check out these resources to move to the next-gen releases:
If you’re using the C#, Node.js, Python, Ruby, or Salesforce helper libraries that we provide in production, we’d recommend continuing to use the current version of the helper library until we make the next-generation version Generally Available. However, if you need to start using the newest functionality that we shipped to the REST API today you can start using the release candidates for the next generation candidates:
We’re incredibly excited to see the next generation of chat experiences you’ll create with even more configurability in the APIs and convenience methods so that you can focus on building customer features.