Every Slack API limit, in one table

Slack's limits are spread across the rate-limit guide, each method's reference page, the Block Kit reference, the Events API documentation, and the app manifest schema. This page collects them with the documented wording and a link to the page that states each one. Values were verified on 2026-08-20 against Slack's current developer documentation (now hosted at docs.slack.dev; api.slack.com URLs redirect there).

Three limit systems matter most in practice. First, Web API rate limits: four tiers from 1+ to 100+ requests per minute, applied "per API method per workspace/team per app", plus a special rule for message posting — about 1 message per second per channel. Exceed any of them and you get HTTP 429 with a Retry-After header stating how many seconds to wait; the error strings are ratelimited and rate_limited. Since May 29, 2025 there is also a much stricter documented limit on conversations.history and conversations.replies for new apps distributed outside the Slack Marketplace — 1 request per minute and 15 objects per request — which changes the economics of history-reading integrations.

Second, Events API delivery rules: acknowledge every event with an HTTP 2xx within 3 seconds, or Slack retries up to three times and — at sustained failure rates above 95% over an hour — temporarily disables your event subscriptions. Deliveries cap at 30,000 per workspace per app per hour, past which you receive app_rate_limited instead of your events.

Third, content budgets: 4,000 characters of recommended message text (hard truncation above 40,000), 50 blocks per message with per-block caps like 3,000 characters of section text and 150 of header text, 100 attachments, and the modal stack's 3 views of 100 blocks each. Exceeding these produces the deterministic errors cataloged in Slack API errors; for diagnosing a bot that has gone quiet, start with Slack bot not responding.

Slack rate limits "per API method per workspace/team per app": each method belongs to a tier, and every workspace-app pair gets its own budget for it. The documentation recommends designing around "a limit of 1 request per second for any given API call", with temporary bursts tolerated. Exceeding a limit returns HTTP 429 with a Retry-After header in seconds — the handling contract is on the ratelimited page, and message-posting overruns surface as rate_limited. Note the 2025 change: new non-Marketplace commercial apps face a documented 1-request-per-minute limit on the two history-reading methods, with responses capped at 15 objects.

The Events API inverts responsibility — Slack calls you — so its limits govern your endpoint's behavior. The contract: respond with an HTTP 2xx within 3 seconds or the delivery counts as failed; failures are retried three times with x-slack-retry-num/x-slack-retry-reason headers; sustained failure gets subscriptions disabled. Volume caps at 30,000 deliveries per workspace per app per hour, past which Slack sends app_rate_limited instead of events. New Request URLs must first pass the url_verification challenge, and every request should be verified against the X-Slack-Signature header.

Message-size limits are enforced with specific error strings, so each row here has a failure page: oversized text returns msg_too_long, empty content returns no_text, and free-workspace ceilings surface as message_limit_exceeded. Note the two-level text rule on chat.postMessage: 4,000 characters is the documented "for best results" budget, while 40,000 is the point past which Slack truncates outright — and chat.update enforces 4,000 as a hard cap. Nothing is chunked for you; splitting and summarizing are your job.

Block Kit budgets exist at two levels — per surface and per block — and violating either returns invalid_blocks (or msg_blocks_too_long for oversized block payloads), while structurally broken JSON returns invalid_blocks_format. The per-surface rule from the Block Kit reference: "You can include up to 50 blocks in each message, and 100 blocks in modals or Home tabs." The per-block numbers below come from each block's own reference page; dynamic content (customer names, descriptions) is what pushes past them in production, so clamp strings before they enter a block. Legacy attachments have count and payload-size ceilings of their own — too_many_attachments documents the count.

Modern uploads go through files.getUploadURLExternal (you declare the byte size, receive an upload URL, then finalize with files.completeUploadExternal); the method sits in Tier 4, so throughput is rarely the constraint — size and workspace policy are. Slack documents per-team restrictions rather than one universal byte ceiling: admins can restrict large uploads (file_upload_size_restricted) or disable uploads entirely, and free workspaces have a documented 5 GB storage pool. Files are the correct escape hatch when content outgrows message text budgets: upload, then post a short message linking the file.

Interactivity has its own clocks and caps. Slash commands must be acknowledged fast — the documentation requires the confirmation "within 3000 milliseconds of the original request being sent" — and a trigger_id from any interaction expires 3 seconds after issue, so opening a modal is always a race you must win before doing slow work. The structural caps below come from the app manifest schema and the modals guide; command definitions that exceed them fail at configuration time rather than at runtime, which at least makes them easy to catch. Modal contents obey the same Block Kit budgets as messages, with the higher 100-block ceiling and failures surfacing as invalid_blocks.