We know there's a lot to learn and read about all the integration points of the Slack platform. That's why we're giving you this. More to read, easier to skim.
We're sure we're missing critical tips. Let us know by tweeting to @SlackAPI!
- General
- Authentication
- Bot users
- Slash commands
- Incoming webhooks
- Web API
- Real Time Messaging API
- Slack apps
There's no explicit sandbox or developer environment available to work against. Instead, you'll need to use a team you've created or are a member of.
It's best to keep your integration or app's ownership contained within the team that is responsible for it.
Whether you're building an integration for your own team or planning to build a Slack app for distribution in the App Directory, begin by building a custom integration.
All three integration types allow you to post messages within a channel but differ in how those messages are triggered and how users interact with your app.
You can use all of these integration types together in your Slack app.
- Incoming webhooks - send messages to a channel at will by using a specific URL. Best used when activity that would incite posting a message occurs in a remote service.
- Example: If you have an issue tracking system and want to post to a channel when a bug is created or resolved, use an incoming webhook invoked from your issue tracking system.
- Slash commands - team members execute slash commands from within Slack, resulting in us triggering your server to return them a message. The message can either be displayed only to the executing user, or to the channel from which it was triggered.
- Example: Your slash command allows users to create and resolve bugs from the Slack command line with either action resulting in a message being displayed to that channel.
- Bot users - Your service monitors channels and direct messages for certain conversational triggers, like specific text in messages posted or emoji responses. As appropriate, your bot user posts messages or performs tasks inside or outside of Slack on a team's behalf.
- Example: Your bot monitors a channel's messages for specific issue IDs and sends the channel a message containing details about them.
- Example: Your bot tracks a team's emoji reactions and sends a message at the end of the day to celebrate those most used.
On their own, custom integrations are for a specific team to use. An incoming webhook is a single custom integration. A bot user is a single custom integration. Same with a slash command. The tokens and credentials used for these custom integrations are intended only for the team that originated them.
A Slack app is a packaged collection of one or more custom integrations made available for Slack teams to install and utilize. Teams will use an OAuth 2.0 authorization flow to approve your app, resulting in team-specific OAuth tokens you'll use on their behalf.
Other differences include:
- Incoming webhooks packaged as Slack apps cannot change their channel, icon, and username at runtime, while custom integration-based webhooks can.
- The permission model afforded to bot users packaged as Slack apps is slightly different. Review the bot user method list for more detail.
When working with Slack apps or Web API, you'll often need to send access tokens, also known as bearer tokens, along with inbound requests using the token query parameter.
Some of the tokens you'll be given while going through the integration creation process. Other tokens you obtain by sending team users through the OAuth 2.0 authentication flow.
When you're working with Slack apps, you'll be awarded access tokens after a user approves your application.
You can also obtain team-specific test tokens for use with the Web API using our token generator, but they should not be shared with the public or other teams.
Your incoming webhooks URLs are unique for your integration or application and do not require token-based authentication. Slash command response URLs also already encode your integration or application's identity.
Webhook URLs generated by rtm.start also encode the information you need to connect, though requesting rtm.start itself requires a token as described above.
When you configure Outgoing webhooks and Slash commands, you specify a URL for Slack to send requests when qualifying conditions are met. Slack also provides you a token related to that integration.
Slack sends that URL a JSON payload containing a token field. Compare that field to values you've received from Slack. See validating slash commands for more information.
Authorization codes must be exchanged for an access token within 10 minutes by calling oauth.access as part of the authorization flow. Otherwise, the authorization code will expire and you will need to ask the user to go through OAuth again.
There is no programmatic way for you to revoke tokens issued to your integration or app. Team members and administrators can remove your app through their team administration interface.
Though it's somewhat of a nuclear option, you also have the ability to revoke all tokens from your developer dashboard by selecting your application and using the Revoke all tokens button found there.
To reset your client secret, go to your developer dashboard, select the application you are concerned about, use the Change secret button found there.
Don't forget to use your new secret when exchanging authorization codes for access tokens while authorizing users and teams with OAuth 2.0.
When a Slack App is approved that contains a bot user, you're awarded two tokens. The bot user token is for performing certain actions directly as the bot user, like posting a message or connecting to the real time messaging API.
If you want to make Web API calls more generally, based on the scopes you've negotiated, you'll want to use the broader token you were awarded at approval time.
Typically, if Slack cannot reach your slash command URL it's because it's either inaccessible, does not have a valid, verifiable SSL certificate, or because our request is timing out for some reason.
Slack invokes slash command URLs from its servers rather than from a Slack client app like Slack for Mac. This means that the URL we're trying to reach must be accessible to Slack's servers.
Keep track of the validation tokens and team IDs Slack gives you when commands are created and teams approve your app. Always validate that the token field in an incoming slash command request has been issued to you by Slack and scope your data for that team.
You won't be able to override any of these fields when using an incoming webhook attached to a Slack app. Instead, those values will be provided from your Slack app configuration and any configuration provided by the team.
If you're using a custom integration, verify that the icon URL you're providing corresponds to a publicly accessible image resource and that the provided username or channel is valid.
Slack rate limits all aspects of platform use with many factors. Rate limits are currently unpublished. Review our rate limiting documentation for more detail.
The guiding spirit of Slack's rate limiting is to ensure that teams are able to communicate effortlessly and without distraction.
Because the limits are unpublished, you won't know that you're about to hit a rate limit in advance. You will receive a HTTP 429 Too Many Requests rate limited message in response to a request and will then need to wait for the next rate limiting window to open.
The next rate limit is indicated by a HTTP header called Retry-After, presented in seconds to wait before attempting another request. If the value were 10, then you should wait 10 seconds or more before retrying that request.
You may find that you can't perform certain bursty actions, like attempting to message every member of a large team simultaneously. In some cases, hitting rate limits may be a symptom that there are better ways to to accomplish your goal. Some times you just need to work slower.
Bot users associated with many teams may hit rate limits while using rtm.start too quickly. Queue up your connection requests or throttle otherwise after your service restarts.
Finally, developers working with the Real Time Messaging API have special considerations worth reading in context.
For more information, consult our rate limiting documentation.
The Real Time Messaging API and other API methods reference file objects that contain a suite of details about the content type of the file and absolute URLs where those files can be retrieved or used for display.
As of January 4th, 2016, applications must provide authentication to access the actual files that file objects reference. There's a blog post discussing this change of behavior.
File objects contain url_private and url_private_download fields, as well as fields for private thumbnail URLs as applicable.
To retrieve these URLs, you must provide a HTTP Authentication header containing a bearer token that's been awarded the files:read or read scopes.
For example, to retrieve a thumb_360 field containing https://files.slack.com/files-tmb/Z0CHK-THSCH5-5SZ0UT/cheese.jpg and your bearer token was VALID_TOKEN, you'd need to send a request like this:
GET https://files.slack.com/files-tmb/Z0CHK-THSCH5-5SZ0UT/cheese.jpg
Authorization: VALID_TOKEN
For public channels, use channels.list to retrieve the list of channels. The list includes each channel's name and id fields.
For private channels, use groups.list. It works the same way.
Many developers keep the list of channels in memory for swifter lookups. Poll the method occasionally to refresh your inventory.
You can use similar instructions to the question above, or you can use dedicated methods to look up a channel by its ID.
For public channels, use channels.info to obtain a specific channel's information, including its name.
For private channels, use groups.info. You'll find everything you want to know about a specific private channel.
Channel IDs remain the same even when the names are changed, but if a channel becomes private the ID will change.
Private channels were first conceived of as group objects, and the names of the objects, events, and methods were chosen then. We decided that "private channels" made more sense for users, but already had developers, both internal and external, using the group namespace.
When you see references to these groups, just rewire your brain to call them private channels instead, even though you'll be calling them group in your code.
The first step is making a typical HTTP request to the rtm.start method. Within that response, you'll find a url field beginning with the URI protocol wss://.
Then, use a Websocket client to open a long-lived connection to that time-sensitive URL. While the connection is open, you'll be streamed events associated with the team you're connecting on behalf of and can in turn send messages.
Typical HTTP client libraries and tools do not support connecting to websockets directly. You will need to find a client library for your preferred programming environment.
- Build your integration points with Slack using Custom Integrations
- Create a Slack app record to package your integration points and obtain your app's platform credentials for use in authentication and the "Add to Slack" button.
- Review this checklist to make sure your app is prepared for approval process.
- Submit your application for review.
- Slack will review your application and approve it if it meets our criteria.
Please be patient as our team regularly reviews submissions. To help the process go as smoothly as possible, we strongly recommend making sure you've followed the checklist before submitting.
Last updated on January 28, 2016.