Updated: 2017-06 APIs
If you've been developing on Slack for awhile you may have noticed a continued theme with updates we make to the platform and APIs: larger teams and evolving use cases mean previous ways of enumerating collections of data become unwieldy and even problematic.
If you don't work with the RTM API or don't utilize
presence_change events, there's very little of value for you in this changelog.
We're introducing two new scalable ways to stay on top of presence change notices in the RTM API.
On large teams especially, folks flock like birds and change their presence at the same time to the same things.
Both to help us dispatch these and for you to consume these reliably, we've introduced a
batch_presence_aware=true parameter to pass to
rtm.connect. Doing so indicates you can receive batched presence events.
These are the
presence_change events you're used to except instead of a single
user field, you'll find a
users field with an array of user IDs.
Maybe your app only needs to know the presence of like five people on a team of thousands. Or five hundred people. Or maybe you need all of those thousands.
Well instead of having no choice but to receive them all, now you can send a
presence_sub=true parameter to
rtm.connect and you'll tell us that you only want
presence_change events for users you're establishing subscriptions for.
Once subscribed, you'll only get those users'
presence_changed events. Subscriptions last only the length of an open websocket connection.
The Events API isn't changing how it handles user presence events — it still stubbornly doesn't support them at all!
You won't receive bulk
presence_change events if you don't opt-in to them using the
batch_presence_aware=true parameter with
You won't need to subscribe to
presence_change events with
presence_sub unless you opt-in to subscription using the
presence_sub=true parameter with
If you don't use the RTM API or don't use
presence_change events — nothing. Do nothing and nothing also happens. Easy.
On very large teams, like Enterprise Grid teams, you might miss some
presence_change events if you don't batch them up. Or you might receive so many at one time that your app blows up.
If you don't use
presence_sub to manage a smaller concern of
presence_change events you might receive so many at one time that your bot forgets its name.
If you want to go "all-in" with both subscriptions and batching, you'll want to do all of the following:
presence_changeevents with a
usersarray instead of a
userstring, and subscribe to these changes using
These new features are available now. Our concern with very large teams is clear and present. Implement them at your leisure, but if you work with Enterprise Grid teams you may want to migrate sooner than later.
If you have any questions or concerns, please contact us.Review other recent updates