Slack error ratelimited: Request was rate limited (HTTP 429)

Your app called this method too often and Slack throttled it. This is the one common Slack error that changes the HTTP status line: the response arrives as HTTP 429 Too Many Requests, and — as the documented description says — you should "Refer to the Retry-After header for when to retry the request." The header value is a number of seconds; the contract is to wait exactly that long, not a guess of your own.

Slack's Web API limits are organized in tiers, applied "per API method per workspace/team per app": Tier 1 allows 1+ per minute, Tier 2 20+, Tier 3 50+, Tier 4 100+, each with some tolerance for short bursts. Each method's reference page states its tier. Because the scope is per-method-per-workspace, a burst of conversations.history calls does not throttle your chat.postMessage traffic — but ten workers all posting to one workspace share one budget, which is why per-worker rate limiters multiply your real rate and fail. Message posting adds its own special rule: about 1 message per second per channel, with short bursts tolerated. Newer non-Marketplace apps face stricter documented limits on conversations.history and conversations.replies (1 request per minute, 15 objects per request) — see the full table in Slack rate limits.

Handling is mechanical. On 429: read Retry-After, sleep that many seconds, retry the same request once, and feed back pressure upstream (pause the queue rather than letting it pile onto the next request). Retrying early is the classic own-goal — it keeps you inside the penalty. The official SDKs do much of this for you: @slack/web-api retries rate-limited calls automatically and emits WebClientEvent.RATE_LIMITED, only surfacing an error with code === ErrorCode.RateLimitedError (which carries a retryAfter property in seconds) if you set rejectRateLimitedCalls: true; Python's slack_sdk raises SlackApiError where e.response.status_code == 429 and e.response.headers['Retry-After'] holds the wait, and ships a RateLimitErrorRetryHandler you can append to client.retry_handlers.

If throttling is chronic rather than incidental, the fix is architectural: batch reads with cursors and larger limit values, cache what you re-fetch, coalesce notifications per channel, and spread bulk sends. A related documented string, rate_limited, appears specifically for message-posting overruns.

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

{"ok": false, "error": "ratelimited"}

Design to the documented tiers from the start: look up each method's tier, provision a shared limiter, and alert on 429 rate rather than on single occurrences (occasional 429s are normal at scale; sustained ones mean the architecture is polling or fanning out too hard). The complete tier table, the per-channel posting rule and the 2025 non-Marketplace changes are collected in Slack API limits, with background in Slack bot not responding.