Updated: 2018-02-06 APIs
Today, we're also announcing the deprecation of the optional
presence parameter in
users.list. Beginning September 26th, 2018, the
presence parameter and corresponding fields will no longer be available from
Developers utilizing user presence state in their applications and integrations should review this guide to the many recent and coming changes to presence.
users.setActive is also deprecated due to underlying functionality not being available in our most modern message servers.
The Web API method
users.list will no longer accept the optional
presence parameter, which instructs the method to return a
presence field with every user object.
Until September 26th 2018, you'll find accurate presence reporting capped at 500 results in large workspaces.
To recap everything that has changed recently with presence:
presence_changeevents without a subscription.
rtm.startwill no longer include initial
presencefields for each user.
users.listnow caps accurate presence reporting at 500 users per workspace. Use
users.getPresenceand/or presence subscriptions instead.
presence_querywrite event over RTM to query the current presence status of a list of 500 users.
users.setActiveno longer prevents users from being marked inactive and will completely cease functioning May 8, 2018.
If your app uses
presence_change events you must subscribe to them before delivery. If you don't need real time presence for every user, use
users.getPresence ad-hoc to look up user presence by ID.
If your app uses the
presence parameter on
users.list or relies on the
presence field in user objects appearing in
rtm.start, you'll want to look up presence on demand using
users.getPresence or the
users.getPresence are intended for frequent, bulk usage. We recommend reducing your dependency on a complete picture of user presence and instead look up presence ad hoc only when it's absolutely necessary for operations.
presence_subwrite event to establish subscriptions.
presence_querywrite event to report on users' current presence status.
If you relied on
users.setActive to prevent a user from being set
away, you'll need to maintain presence another way like opening a RTM connection or using
By not receiving the
presence_change events your app is looking for, or by not getting the initial state of presence from
users.list with the
presence parameter, your app won't know whether users are present or not (that is,
If your app or bot only contacts users it detects as
presence, your bot may have trouble interacting with users.
If your app tracks presence for some other reason, the tracking might not be accurate.
If your app is already using subscriptions but is not batching presence events, you may receive floods of
presence_change events in large workspaces.
If your app only uses
users.getPresence to determine presence, nothing changes.
users.getPresence functions as usual.
If your app sets
users.list, you'll need to adapt to using
users.getPresence and/or presence subscriptions by September 26, 2018. By doing nothing now, your presence results are capped at 500 users.
Your requests to
users.setActive will appear successful but will not actually prevent a user from being marked
away. Eventually, the method calls will return a HTTP 400-series code.
As of January 2018, presence subscriptions are already required and
rtm.start no longer returns
presence for its list of users.
On May 8, 2018
users.setActivewill completely cease functioning May 8, 2018. Until then, it is a no-op.
On September 26, 2018, the optional
presence parameter in
users.list will no longer function.
Please contact us with your concerns at email@example.comReview other recent updates