Every Slack API rate limit, in one table

Slack rate-limits its Web API per method, per workspace, per app, with windows of one minute. Each method is assigned a tier: Tier 1 allows 1+ requests per minute, Tier 2 allows 20+, Tier 3 allows 50+ and Tier 4 allows 100+. A "special" tier covers methods with their own rules. The most important special rule is message posting: "no more than one message per second per channel," whether through chat.postMessage, an incoming webhook or any other route. The tiers are the same on every Slack plan, so paying for Slack does not raise them.

The biggest recent change is to conversations.history and conversations.replies. Since May 29, 2025, commercially distributed apps that are not approved for the Slack Marketplace ("unlisted" apps) are limited to 1 request per minute on these methods, with at most 15 objects per request. The limit applies to new apps and to new installations of existing unlisted apps. Marketplace apps and internal customer-built apps are not affected, and Slack's changelog says existing installations of unlisted apps are not impacted.

Values below come from Slack's developer documentation (docs.slack.dev; api.slack.com redirects there), verified November 12, 2026. Slack notes that each tier's limits are subject to change.

Every Web API method's reference page lists its tier in the Facts section. The "+" matters: Slack documents minimums and tolerates bursts above them, but does not publish exact burst limits. Its design advice is to plan for 1 request per second per method and treat anything above that as a temporary burst. Limits are evaluated per method, per workspace, so a 429 on one method doesn't block other methods or other workspaces. Methods that support cursor pagination get stricter limits if you call them without paginating.

Message posting is limited per channel rather than per method, and the limit covers every way of posting. Slack allows short bursts above 1 per second but warns that burst messages are not guaranteed to be stored or displayed. It also says that apps which keep exceeding the limit after being rate-limited risk being permanently disabled. On top of the per-channel rule, chat.postMessage has a workspace-wide ceiling of "several hundred messages per minute."

These two methods read message history, and since May 29, 2025 their limits depend on how your app is distributed. Marketplace-approved apps and internal customer-built apps keep Tier 3 (50+ per minute), and the limit parameter goes up to 999 on conversations.history. Commercially distributed apps that are not in the Marketplace drop to Tier 1 for new apps and new installations: 1 request per minute, with the default and maximum limit reduced to 15 objects. Slack's stated reason is to prevent bulk data exfiltration by unvetted apps.

The Events API inverts the direction: Slack calls your endpoint, and the limit caps how many events Slack will deliver to your app per workspace. When exceeded, Slack sends an app_rate_limited event instead of the events. Workflow Builder triggers and AI steps have their own published limits, which matter when a workflow is the integration point rather than a custom app. The RTM API, now legacy, limits writes to 1 per second and connection calls to 1 per minute.

Over-limit HTTP calls, including incoming webhooks, return HTTP 429 Too Many Requests with a Retry-After header giving the number of seconds to wait. Slack's example is HTTP/1.1 429 Too Many Requests with Retry-After: 30. The JSON error is ratelimited: "The request has been ratelimited. Refer to the Retry-After header for when to retry the request." chat.postMessage can also return rate_limited: "Application has posted too many messages, read the Rate Limit documentation for more information."

The block lasts only for the method and workspace that hit the limit. Other methods and other workspaces keep working. Repeatedly exceeding posting limits can get an app permanently disabled. For Events API overages, Slack sends an app_rate_limited event instead of your events for the rest of the window.

Honor Retry-After exactly. Slack's official SDKs (Bolt, the Python and Node clients) can queue and retry on 429 for you.

Use one shared limiter per workspace and method. Limits are per app, so ten workers posting in parallel share one budget.

Paginate and cache. Always use cursor pagination, since unpaginated calls get stricter limits, and cache results of users.list and conversations.list instead of re-fetching them.

Consolidate messages. Post one summary message or thread reply instead of a burst of single-line posts into one channel.

Submit to the Slack Marketplace if you distribute an app commercially and need history access. Marketplace approval restores Tier 3 limits on conversations.history and conversations.replies, and Slack does not charge for listing.