31 posts tagged with "Breaking change"

We want to update you about our previous announcement regarding support for classic apps. After much consideration and feedback, we have decided to push back the deprecation date to May 25, 2026.

We want to update you about our previous announcement regarding support for the files.upload API method. After much consideration and feedback, we have decided to push back the deprecation date to November 12, 2025.

We previously mentioned that we had deprecated the deno command and removed its listing from the help command. We have now removed the deno command completely. Developers who were depending on this command should now use the deno executable directly.

We've also removed support for the deprecated, pre-release Deno Slack SDK versions that used slack.yaml and project.ts files. The Run-on-Slack platform no longer supports the slack.yaml file format, and no production projects should be affected. The project.ts file was deprecated by the Deno Slack SDK in favor of manifest.ts and manifest.json files.

We want to update you about our previous announcement regarding support for legacy custom bots and classic apps. After much consideration and feedback, we have decided to push back the deprecation date for classic apps by 6 months: we will now discontinue support for them on March 31, 2026 May 25, 2026. Nothing will change for legacy custom bots, of which the original deprecation date was March 31, 2025.

We want to let you know about some upcoming changes to support for legacy custom bots and classic apps on the Slack platform.

• Beginning March 31, 2025, we will discontinue support for legacy custom bots. For your integrations to continue working, you must create brand new Slack apps.
• In September 2025 March 2026 May 2026, we will discontinue support for classic apps. For your apps to continue working, you will need to migrate them to Slack apps.Any custom bots or classic apps you have built will no longer work after these dates.

It has been over 10 years since we originally launched the Slack Platform. As we mentioned back in April 2024, there are just too many ways to create an app, so we're doing our best to streamline this process. Beginning March 31, 2025, we will discontinue support for legacy custom bots. In May 2026, we will discontinue support for classic apps. Read on for more details about how this will affect your integrations and apps.

As of May 16, 2024, newly-created Slack apps are no longer able to access the files.upload API method. Learn how to use our new asynchronous upload flow to migrate your existing apps and integrations by March 11, 2025.

Learn more about what this means for your steps and workflows in this changelog article and survival guide.

The original web API method for uploading files to Slack, files.upload, is being sunset on March 11, 2025 November 12, 2025.

As of May 16, 2024, newly-created apps are no longer able to use this API method.

Existing apps & integrations should migrate away from files.upload and instead leverage a combination of two APIs: files.getUploadURLExternal and files.completeUploadExternal. The use of these two methods is more reliable, especially when uploading large files.

A detailed breakdown of how to use these two API methods is described in our Uploading files documentation.

We're retiring support for traditional Slack apps providing Steps from Apps to our legacy workflow builder and workflows created with it. Read on to learn whether your apps or workflows are impacted.

Starting in March 2023, Slack began rolling out a new collection of features collectively called Save it for Later. It gives you a new Later section on Slack where things you save for later (with or without a reminder attached to it) are kept.

This new collection of features replaces our previous Saved Items (also known as starred items, or just stars) and Reminders features.

As part of this new feature roll out, the existing APIs to interface with saved items and reminders have become degraded or useless. There are no direct APIs for Save it for Later to integrate with. With the current suite of built-in functions, web API methods, events, and triggers offered by Slack it is possible to recreate some (but certainly not all) use cases the impacted APIs supported.

We aim to give ample notice for every platform feature developers would consider a “breaking change.” We apologize we were unable to provide this information to developers ahead of the Save it for Later release.

The original way to connect to one of our oldest APIs is finally retiring. For existing apps, rtm.start will start behaving exactly like rtm.connect on September 27, 2022. Beginning November 30, 2021, newly created apps and integrations will only be able to use rtm.connect.

The RTM API remains available to developers using rtm.connect.

Hello! You are here because three monumental things changed on the Slack platform today, February 24, 2021.

On August 24, 2021, legacy workspace apps were retired. Workspace apps were part of a brief developer preview we elected to not fully release. Since October 2018, existing workspace apps have remained functional but on August 24, 2021 workspace apps will be retired and no longer function.

Please read on if you were the developer, maintainer, administrator, or user of a vintage workspace app.

Don't know if you have a workspace app? Make sure you're signed in to all your workspaces and visit our deprecation center. Each workspace app you own or collaborate on will be listed.

Your app's events—received from the Events API—are changing.

Event payloads will no longer contain a full list of authed_users or authed_teams. These two fields will be deprecated. There'll be a new, compact field called authorizations to replace them—but authorizations will only contain at most one person or workspace that the event is visible to.

If you need a full list of all the parties an event is visible to, you'll call the apps.event.authorizations.list method.

The new, streamlined shape of events allows Slack to deliver them faster.

These changes to the Events API will take place on February 24, 2021. You'll be able to opt in to them earlier, on September 29, 2020, by going to your app settings and selecting the checkbox under Event Subscription.

In order to get ready for the changes to authorizations, you can use the apps.event.authorizations.list method even without opting in to the new shape of events, starting September 29, 2020.

Read on for more details on what's changing and how to prepare.

We're deprecating legacy test tokens and will disallow the creation of new test tokens beginning May 5th, 2020.

We launched Slack apps over four years ago as a replacement to the number of ways one could obtain overly-permissive tokens to integrate with Slack.

If you or a software product you author relies on test token creation, you will need to migrate to using Slack apps with specifically named scopes instead.

Existing tester tokens will continue functioning but tokens left unused are subject to periodic revocation.

We released the Conversations API in September 2017 as a one-size-fits-all replacement for a variety of APIs used to read and write information about channels, private channels, direct messages, and multi-party direct messages.

Today we are announcing the deprecation of the methods that preceded the Conversations API (channels.*, groups.*, im.*, & mpim.*). On November 25th, 2020 February 24th, 2021 these methods will retire and cease functioning.

If users expect your app to work in channels of any kind, you'll want to verify you're using the Conversations API for all channel types.

We resolutely recommend migrating to the Conversations API immediately.

When your app, custom integration, or bot communicates with Slack via HTTP, it uses TLS (Transport Layer Security) to ensure data privacy and integrity.

There are multiple major versions of TLS, including v1.0, 1.1, 1.2, and 1.3. Versions 1.0 and 1.1 are deprecated and should no longer be used.

On March 4, 2020, we'll require all communications with Slack to use TLS version 1.2 or greater.

All TLS connections must use the SNI extension. Lastly, TLS connections must support at least one of the following supported cipher suites:

• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES128-SHA
• ECDHE-RSA-AES256-SHA
• AES128-GCM-SHA256
• AES256-GCM-SHA384

Using TLS version 1.2 or greater makes Slack safer for everyone.

We're modernizing the GET /Users and GET /Groups methods of our SCIM user management API by putting a more reasonable upper bound on results served per page.

The SCIM spec allows for pagination and these methods have long supported it, but we've accepted higher count values in the past.

The changes described below are effective July 8th, 2019 August 30th, 2019.

The data structure that represents a message now contains additional new fields on top of all the existing fields your app may be currently expecting. The new structure took effect on February 13, 2019.

These changes come with Block Kit—a new set of components for Slack apps that can be combined to create visually rich and compellingly interactive messages. You can read more about Block Kit below.

Even if you aren't using Block Kit to compose messages, its launch still affects the data structure of messages received via our APIs, so read on to learn how to prepare your apps.

Unless your app uses the Conversations API, you'll encounter unusual results working with more exotic channel types, like shared channels and those channels converted from public to private.

We've added the message.app_home event for workspace apps building on our developer preview.

If you subscribe to message.im events to receive messages between users and your app in the special kinds of 1:1 conversations had in your app homes, you must add a subscription to message.app_home to continue receiving and acting on those messages.

Workspace apps grant apps a dedicated space within Slack where members can interact directly— we call it your App Home. Apps can use this space for personal notifications, onboarding information, and other helpful features.

We're fixing file comments and in the process we're phasing out some related API methods and events.

File comments look like messages in a channel but they aren't. They travel with files, wherever shared, disrupting conversation at inopportune moments.

We started to gradually roll out file threads on July 23, 2018. Sharing a file with a channel will now create an actual message instead of something that looked convincingly like a message. People and bots may reply to that message as they would any other message. You can even upload files into threads.

We're simplifying the installation process for workspace apps.

Now workspace apps can and should use the oauth.access method instead of oauth.token during the verification code exchange phase of app installation via OAuth 2.0.

When used with workspace apps, the response for oauth.access morphs into a response similar to that of oauth.token, but with a few improvements detailed below.

Now oauth.access may be used by workspace apps instead of oauth.token, simplifying a common hurdle when getting started with workspace apps.

Finally, we're replacing apps.permissions.info with apps.permissions.scopes.list and apps.permissions.resources.list.

We're simplifying some permission scopes as part of the workspace apps developer preview.

Beginning today, workspace apps must request files:write instead of files:write:user during installation or when seeking elevated permissions.

Now files:write represents your app's ability to upload and manage files.

Experiencing déjà vu? This is just like that time we did this for chat:write.

The RTM API's presence_change event is now only available via presence subscriptions and rtm.start no longer includes user presence status in its response.

We incrementally announced these changes in June and October 2017.

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 users.list.

Developers utilizing user presence state in their applications and integrations should review this guide to the many recent and coming changes to presence.

Update: users.setActive is also deprecated due to underlying functionality not being available in our most modern message servers.

Legacy workspace apps are deprecated and will retire in August 2021. Learn more.

We're simplifying some permission scopes as part of the workspace apps developer preview.

Beginning today, workspace apps must request chat:write instead of chat:write:user during installation or when seeking elevated permissions.

Now chat:write represents your app's ability to post messages in the channels and contexts granted to it.

Beginning November 15, 2017, the RTM API's presence_sub event will be available via presence subscription only.

Back in June, we introduced new ways to track user presence and the presence_change event in the RTM API.

Dispatching presence events for all users in a workspace is an expensive operation for Slack. A flood of presence events from large workspaces can also disrupt your app's ability to process more useful, timely messages.

By subscribing only to the presence events your app needs to provide presence-dependent functionality, you can reduce unnecessary websocket traffic.

Arrays of members found in API methods will become truncated beginning December 1, 2017.

Initially, Slack will limit members to the first 1,500 users and then gradually lower the number of users returned. You should expect API methods will cease returning members entirely at some point in the future. If you rely on the members array, you should instead begin using conversations.members for a full list of members.

As Slack teams continue to grow in size, returning the full members array in these methods is no longer practical or performant, for the Slack APIs or developers. The conversations.members method will allow you to request a list of members at a time that makes sense for your app and should keep these method calls nice and zippy.

Slack is phasing out the @username artifact in favor of the more expressive and flexible concept of display names.

Handles, aliases, call-signs, and usernames — in chat, they all repersent the same concept: a way for an individual or entity to indicate a preferred identification noun, in whichever way is appropriate to the apparatus at work.

Users will be even better equipped to present their preferred nomenclature while giving organizations the option to work primarily with so-called real names as suits "the suits."

The transition should be technically "backwards compatible" to you, the developer. But the social ramifications, changes in user behavior, and treatments given in Slack clients will inevitably alter the way your apps approach interpreting, storing, and utilizing the now deprecated name field.

As fellow developers, we know you'll have some feelings about the sunset of @username considering its historical significance in computing, networking, and digital identity. From mainframes to UNIX to BBSes to IRC, maybe you've used the same name for what seems like centuries.

Fly your freak, geek, or mild-mannered flag proudly by just setting your display name to your preferred @username.

Update 2017-07-12: As promised, the latest fields within rtm.start's channel objects are no longer returned. Additionally, the unread_count and unread_count_display channel fields are also missing, though they can still be found in conversations.info.

rtm.start began life as a broker and bootstrap to Websocket connections established by Slack's desktop and mobile clients. Whenever our clients needed more information to establish state, those fields would get stuffed into the cacophony that is rtm.start's opening salvos.

As team sizes and feature complexity has grown, delivering this immense quantity of information about nearly every user, channel, and conversation on a team has become more difficult to compute, consume, or continue.

It is in this spirit we offer a friendlier alternative in rtm.connect, a method born with the sole purpose of reserving a websocket connection and providing your application its URL.

rtm.start must evolve to continue functioning well for all teams and apps. We strongly recommend using rtm.connect to establish your connections alongside Web API methods to build your app's understanding of the users, channels, and conversations within a team.

One such change coming to rtm.start is the elimination of the latest attribute assigned to each channel in its response.

On July 11, 2017 we'll no longer return these latest fields. If your app needs a channel's latest timestamp value, use conversations.info to retrieve it instead.

You can test this future behavior in rtm.start today by providing the no_latest=1 parameter.

If you parse events referencing files in the real-time messaging API, you may have noticed we send a sometimes comically large packet of information when streaming nearly anything related to a file.

To improve performance and provide a better user experience, we're reducing the payload of most file-related events in the RTM API to include only the file's ID. You'll need to use the files.info API method to retrieve additional information about files.

These changes will roll out gradually beginning May 16th, 2016 — read below to understand how this change may effect you, especially if you work with bot users.

Bot users will gain comparable capabilities, allowing bot user tokens to work with files.info based on the channel memberships and related capabilities granted to them.