Apps have access to the full scope of the platform, paving the way for more enhanced and powerful experiences in Slack. To make this magic happen, every Slack app has access to a bag of tricks — a range of APIs that provide access to read, write, and update all kinds of data in Slack.
Some of these features mirror what users can do in Slack clients:
You can create welcoming spaces for people to use your Slack apps by using the range of possible app surfaces. A surface is anywhere an app can express itself and interact with users.
Surfaces are composed using a collection of puzzle pieces called Block Kit. Because these visual components are designed by Slack, they have a consistent look and feel across every client, and for every user.
Apps can use a combination of surfaces. Just because the invocation happened in a channel doesn't mean that the other members of that channel need to see the rest of the process, or even the end result.
Perhaps the right thing to do is to take things to a modal - where information can be quietly collected, decisions privately made, and workflows finalized.
Slack apps can use interactive features to achieve two-way communication between Slack apps and users. The interactive flow is a two step process:
There are multiple ways to invoke the interaction, and apps have multiple ways to respond.
Your app can be invoked without any direct user input due to the following:
Users can invoke apps by using one of the following entry points:
When you're planning your Slack app, the question is — which of these entry points is most appropriate?
For example, if you know your audience has a lower familiarity with interactivity, Slash commands may be difficult for them to use.
Slack users are people of all ages, races, genders, and ability levels. They may have poor internet connections, use Slack only on mobile, or they might never have used a Slack app before. We want them all to have a great experience on Slack, so be sympathetic of your audience when designing your app.
In many cases, the answer could be using all of the entry points. Your app can accomplish many different tasks, with each being best suited to a different entry point.
The Slack platform is composed of several APIs that let you build apps of all shapes and sizes. Generally, these APIs work together but there’s also a bit of overlap that can sometimes be confusing. This section will help you find the right API for your project.
With the Events API, you pick the events you’re interested in receiving and Slack will send them to an endpoint you specify via HTTP.
If you don't wish to expose a public, static HTTP endpoint to communicate with Slack, Socket Mode can help.
If the Events API is how Slack pings your app, the Web API is how your app pongs back to Slack. Often, this will be because you want to take some action on a Slack workspace, such as composing a message or creating a new channel. Other times, it’s because you want to request something directly, such as a list of all the people in a workspace.
The Conversations API is a subset of the Web API, meaning it’s a set of functions you use to call Slack directly. These functions deal specifically with all of the various channel-like objects that can exist in a Slack workspace, specifically public and private channels, shared channels, external shared channels, DMs, and multiparty DMs.
For the most part, these channel-like objects all behave the same (you can list the users in them, for example), however each conversation will have unique attributes, such as how private it is or whether it's shared across workspaces.
Socket Mode allows you to use the Events API and interactive features of the platform—without exposing a static HTTP endpoint to receive payloads. Instead, you use the WebSocket Protocol and generate a URL at runtime.
Our range of SDKs, frameworks, and construction tools can streamline the process of building a Slack app.
Bolt handles much of the foundational setup so you can focus on your app's functionality. Out of the box, Bolt includes:
Bolt also has built-in type support, so you can get more work done right from your code editor.
If you prefer to build the foundations of your app yourself, you can still avail of an SDK to cut down on boilerplate code.
Instead of building your own authentication handling or generating HTTP requests for Web API calls, just use built-in SDK classes and methods.
There are a range of other development tools available to help you out. A few notable ones:
A visual prototyping tool for surfaces. Stack blocks to preview blocks in all surfaces and get a feel for interactive elements.
Your sidekick for developing tests for your Slack app. Record and replay your HTTP requests to generate fixtures for your tests.
A Slack app that helps you build Slack apps. Quickly look up documentation from within Slack, investigate the structure of messages, and more.
See a full list on our Tools page.
There are many different combinations that can be created, from a single-purpose tool to a complex, interactive service integration.
The following are some resources to guide you along your journey:
Only members on the same workspace as the app can be added as collaborators. This is particularly important on Enterprise Grid, since the member must be a part of the Enterprise Grid workspace where the app was created. If you have single or multi-channel guests in your workspace, you may assign them as collaborators. Guests cannot delete a Slack app; they also cannot modify your carefully pruned roster of co-conspirators.
Keep the end-goal in sight like a guiding horizon: a user wants to accomplish something with your app. The rest is getting there as productively and pleasantly as possible.
Now is the time to build an app that will help make other people’s working lives simpler, more pleasant, and more productive.