Slack API Rate‑Limit Reset Mechanism: Fixed Window or Sliding Window?

Uncertain Reset Behavior

Slack’s Web API advertises a 50‑request‑per‑minute limit per token, yet the exact reset strategy remains undocumented. When a 429 response arrives, the Retry-After header can vary, and the X‑RateLimit‑Reset value on successful calls is not clearly tied to a fixed minute boundary.

Goal

Determine whether the limit is enforced as a strict per‑minute window or a sliding window that permits short bursts, and how this impacts burst‑pattern design in high‑traffic clients.

Constraints & Uncertainty

Observations show inconsistent Retry-After values, unclear shared limits across multiple processes, and endpoint‑specific variations. The behavior is critical for avoiding unnecessary 429 errors during peak usage.

Specific Questions

1. Is Slack’s per‑token rate limit applied as a fixed window resetting every minute, or does it use a sliding window that can accommodate short bursts beyond the nominal 50‑req/min?
2. When a 429 is received, is the Retry-After header deterministic relative to the window reset point, or can it vary independently?
3. Do concurrent requests from multiple processes using the same token share a single global rate limit, or is the limit enforced per process?