Does Slack Events API Retry Guarantee Delivery Without event_id Deduplication?

When a Slack Events API handler takes longer than roughly three seconds to respond, Slack treats the delivery as failed and retries with backoff. The request includes retry metadata such as X-Slack-Retry-Num and X-Slack-Retry-Reason, though the exact retry count and delay schedule are version-sensitive and should be confirmed for your app.

Because retries combined with lost acknowledgments make delivery at-least-once rather than exactly-once, the envelope's event_id is the documented deduplication key. A common design decision is whether to acknowledge quickly and process asynchronously, which decouples handler latency from the three-second window but pushes duplicate suppression onto the consumer via an idempotency store with a retention window.

Does Slack's retry schedule guarantee eventual delivery without application-level deduplication, or must every handler deduplicate by event_id? If an app acknowledges with 200 after enqueuing work, does that eliminate the risk of duplicate side effects from redelivery? How should teams weigh the retention cost of an idempotency store against the likelihood of overlapping retries in production?