You must enable javascript in order to use Slack. You can do this in your browser settings.
Go to Slack

Rate Limits

The rundown
Read this if:You want to share and distribute your app.
Read first:Slack Web APIIntroducing Block Kit
Read next: Methods

Slack platform features and APIs rely on rate limits to help provide a predictably pleasant experience for users.

The details of how and when rate limiting works differs between features. This article gives an overview of the rate limits you're likely to encounter for Slack platform features, and then notes how the limits apply to each feature.

Overview

Broadly, you'll encounter limits like these, applied on a "per app per workspace" basis.

Feature/API Limit Note
Web API Tier 1 1+ per minute Access tier 1 methods infrequently. A small amount of burst behavior is tolerated.
Web API Tier 2 20+ per minute Most methods allow at least 20 requests per minute, while allowing for occasional bursts of more requests.
Web API Tier 3 50+ per minute Tier 3 methods allow a larger number of requests and are typically attached to methods with paginating collections of conversations or users. Sporadic bursts are welcome.
Web API Tier 4 100+ per minute Enjoy a large request quota for Tier 4 methods, including generous burst behavior.
Web API Special Tier Varies Rate limiting conditions are unique for methods with this tier. For example, chat.postMessage generally allows posting one message per second per channel, while also maintaining a workspace-wide limit. Consult the method's documentation to better understand its rate limiting conditions.
Posting messages 1 per second short bursts >1 allowed
Incoming webhooks 1 per second short bursts >1 allowed
Events API events 30,000 deliveries per hour per workspace. Larger bursts are sometimes allowed.

Read on for more details on how rate limits are applied to different Slack features and APIs.


Web API rate limiting

Your app's requests to the Web API are evaluated per method, per workspace. Rate limit windows are per minute.

Each Web API method is assigned one of four rate limit tiers, listed above. Tier 1 accepts the fewest requests and Tier 4 the most. There's also a special tier for rate-limiting behavior that's unique to a method.

All Slack plans receive the same rate limit tier for each method.

The Facts section of each method's reference documentation will indicate its rate limit tier. Check out the channels.list documentation for an example of a Tier 2 method.

Each tier's limits are subject to change.

Pagination limitation

For methods supporting cursored pagination, the rate limit given applies when you're using pagination. If you're not, you'll receive stricter rate limits—for example, you'll be allowed to make fewer requests if you attempt to fetch all of users.list without pagination.

Responding to rate limiting conditions

If you exceed a rate limit when using any of our HTTP-based APIs (including Incoming Webhooks), Slack will return a HTTP 429 Too Many Requests error, and a Retry-After HTTP header containing the number of seconds until you can retry.

For example, if your app exceeds the rate limit of conversations.info, you might receive a raw HTTP response like this:

HTTP/1.1 429 Too Many Requests
Retry-After: 30

This response instructs your app to wait 30 seconds before attempting to call conversations.info with any token awarded to your app from this workspace.

Calls to other methods on behalf of this workspace are not restricted. Calls to the same method for other workspaces for this app are also not restricted.

By evaluating the Retry-After header you can wait for the indicated number of seconds before retrying the same request or continuing to use that method for this workspace.

Limits when posting messages

In general, apps may post no more than one message per second per channel, whether a message is posted via chat.postMessage, an incoming webhook, or one of the many other ways to send messages in to Slack.

We allow bursts over that limit for short periods. However, if your app continues to exceed its allowance over longer periods of time, we will begin rate limiting.

If you go over these limits while using the Real Time Messaging API you will receive an error message as a reply. If you continue to send messages, your app will be disconnected.

Continuing to send messages after exceeding a rate limit runs the risk of your app being permanently disabled.

Rate limits exist because Slack is primarily a communication tool for humans. We try to detect apps acting spam-fully, unintentionally or not, and quiet them down to avoid hindering a workspace's ability to communicate and use their archive.

What if your app requires a higher volume of messaging? Other services provide an interface for logging, searching, aggregating, and archiving messages at higher throughputs. These include Papertrail (which integrates directly with Slack), Logentries (also integrates with Slack), Loggly, Splunk and LogStash.

Events API

Event deliveries to your server via the Events API are rate limited to 30,000 deliveries per workspace per hour.

When a workspace generates more than 30,000 events, you'll receive an informative event called app_rate_limited, describing the workspace and timestamp when rate limiting began.

{
    "token": "Jhj5dZrVaK7ZwHHjRyZWjbDl",
    "type": "app_rate_limited",
    "team_id": "T123456",
    "minute_rate_limited": 1518467820,
    "api_app_id": "A123456"
}

Learn more about Events API rate limiting and our tolerance for delivery failures.

RTM APIs

Message delivery

Message delivery to your app is not rate limited over RTM. You'll receive every event the connecting token is allowed to see. You may receive more events than you can come up with, so we recommend decoupling your processing of events from the receiving of them.

Posting messages

Rate limits do apply to posting messages or other write events to the Real Time Messaging websocket. Please limit writes to 1 per second.

If you sustain writes beyond these limits when using our Real Time Messaging API you will receive an error message as a reply. If you continue to send messages your app will be disconnected.

The message server will disconnect any client that sends a message longer than 16 kilobytes. This includes all parts of the message, including JSON syntax, not just the message text. Clients should limit messages sent to channels to 4000 characters, which will always be under 16k bytes even with a message comprised solely of non-BMP Unicode characters at 4 bytes each. If the message is longer a client should prompt to split the message into multiple messages, create a snippet or create a post.

Obtaining websocket URLs

Rate limits also apply to the rtm.start and rtm.connect methods for obtaining the URL needed to connect to a websocket.

Limit requests to these methods to no more than 1 per minute, with some bursting behavior allowed. If you enter rate limit conditions when trying to fetch websocket URLs, you won't be able to reconnect until the window passes.

Other functionality

We reserve the right to rate limit other functionality to prevent abuse, spam, denial-of-service attacks, or other security issues. Where possible we'll return a descriptive error message, but the nature of this type of rate limiting often prevents us from providing more information.