HTTP 429 Rate Limit Response in Slack Web API

1. Immediate Answer

1. Strict blocking sleep is safe but often sub‑optimal for high‑throughput services. 2. A client‑side token‑bucket limiter is the preferred proactive approach when you can model Slack's tier limits accurately. 3. A hybrid strategy—token bucket for normal traffic, sleep on 429 for safety—offers the best trade‑off between throughput and compliance.

2. Why the Slack Docs Leave It Open

Slack's API returns HTTP 429 with a Retry-After header (seconds). The header is the authoritative wait time for that specific request, but the docs do not mandate a single client pattern. Teams therefore choose between reactive sleeps, proactive limiting, or a mix.

3. Confirmed Facts

• HTTP 429 + Retry-After means the request must be retried after the stated seconds.
• Slack also returns {"ok":false,"error":"ratelimited"} on some legacy endpoints; treat it the same as 429.
• Blocking a thread for the full Retry-After guarantees compliance but serializes all requests on that thread.
• A token‑bucket can enforce the steady‑state rate (e.g., Tier 3: 50 req/min) and smooth bursts.
• Even with a perfect bucket, a 429 may still arrive due to shared limits or sudden spikes; a reactive sleep is still needed as a safety net.

4. Practical Steps for Your Client

1. Determine your app's tier limits. Look up the current per‑endpoint quota in the Slack API docs.
2. Implement a token‑bucket per endpoint group. Capacity = 80 % of the tier limit; refill rate = tier limit / 60 s.
3. When a request is made:
   1. Try to consume a token. If successful, send the request immediately.
   2. If the bucket is empty, fall back to a non‑blocking delay equal to the Retry-After value from the last 429 response (or a conservative default).
4. On receiving a 429, immediately sleep for the header value and then retry, regardless of the bucket state.
5. Periodically log the bucket's fill level and the frequency of 429s to verify that the bucket size is adequate.
6. For multi‑process deployments, use a shared store (Redis, etcd) or keep per‑process buckets with headroom to avoid coordinated overshoot.

5. When to Prefer One Over the Other

• If your service is lightly used (<10 req/s) and you can afford thread starvation, a simple sleep works.
• For high‑throughput or event‑driven workloads, the token‑bucket is essential to keep threads free.
• Hybrid is almost always the safest: the bucket handles steady traffic, and the sleep handles unexpected spikes or shared‑limit violations.

6. One Diagnostic Detail to Request

What is the typical Retry-After value you observe under peak load? Knowing the maximum wait time helps set a sensible upper bound for your sleep logic.

7. Verification Checklist

• Confirm the Retry-After header units are seconds.
• Verify your bucket parameters against the latest Slack tier limits.
• Simulate 429 responses in a staging environment to measure p99 latency with each strategy.
• Ensure your HTTP client does not automatically retry 429 without your control.