Important Changes to Files in the Web API

We are about to launch changes that will affect apps built on the Slack Web or RTM APIs. If that applies to you, continue reading! If not, feel free to continue on your merry way.

What’s Changing

The Slack Web and RTM APIs return file objects in several places including files.info and files.list. Within the file object, there are several attributes including URLs for direct download and thumbnails of the file. For example:

{
 …,
 “url”: “https:\/\/slack-files.com…”,
 “url_download”: “https:\/\/slack-files.com…”,
 “url_private”: “https:\/\/slack.com…”,
 “url_private_download”: “https:\/\/slack.com…”,
 “thumb_64”: “https:\/\/slack-files.com…”,
 “thumb_80”: “https:\/\/slack-files.com…”,
 “thumb_360”: “https:\/\/slack-files.com…”,
 “thumb_360_gif”: “https:\/\/slack-files.com…”,
 …
}

Thumbnails, url, and url_download can be downloaded directly. url_private and url_private_download currently require an authorization header with a token that has either the files:read or read scopes, like:

Authorization: Bearer A_VALID_TOKEN

To help better secure files, the following changes will go into effect on Monday, January 4, 2016:

• url and url_download will no longer be returned in file objects
• the URLs provided for thumbnails (those returned with thumb_* attributes) will require the same authorization header as url_private and url_private_download. Although the header won’t be required until 1/4/2016, you can begin sending it with requests now.

What Else?

For reference, we’ve updated the documentation for file objects here. Although the changes won’t be required until 1/4/2016, we highly recommend updating your app as soon as you can. We know this move to a more robust authentication model for files may require big changes to how your app displays file information, and we’re here if you have any questions. Just send us a note at feedback@slack.com, and we’ll help as best we can.