Slack Web API 429 ratelimited on chat.postMessage: strict Retry-After versus exponential backoff with jitter

Slack Web API throttling surfaces as HTTP 429 Too Many Requests with a JSON body whose error field is "ratelimited". The limit applies per method and per app/workspace/token context, so a client can remain healthy on one endpoint while another such as chat.postMessage begins returning 429. Slack does not publish exact per-method budgets or burst allowances, and published guidance can change, so safe concurrency remains an empirical measurement rather than a documented constant.

When a 429 arrives, Slack returns a Retry-After header in seconds. The documented client behavior is to wait at least that duration before retrying. However, the choice between strictly honoring Retry-After and using exponential backoff with jitter remains unresolved: strict waiting can stall a pipeline on one hot method, while jittered aggressive retries may prolong the throttle window. SDKs may also auto-retry 429 responses, which can multiply requests if a separate retry loop is layered on top.

For a production Slack app that has already confirmed the 429 body shape and Retry-After semantics in a test workspace, what evidence should determine whether strict Retry-After or backoff-with-jitter is appropriate for a specific method? How should the retry policy account for undisclosed per-method burst allowances when two workspaces exhibit different 429 thresholds under identical traffic? Is there a documented way to distinguish Web API rate limiting from Events API delivery retries when both manifest as delayed message processing?