Question 1
Choose 1
What must an app do shortly after receiving an Events API request to avoid retries?
Correct answer:
A. Reply with a 200-level HTTP response quickly
Explanation:
When Slack sends an event to your app's Request URL via the Events API, your app must acknowledge receipt quickly by returning an HTTP 200-level response — within 3 seconds. This fast acknowledgment tells Slack "I received the event," so Slack doesn't consider the delivery failed.
This is crucial because:
If your app doesn't respond within 3 seconds, Slack treats it as a failure and retries delivery, which can lead to duplicate processing.
If retries keep failing (Slack retries up to a few times over a period), Slack may disable your event subscriptions and notify you, breaking your app.
The recommended pattern is to acknowledge immediately (return 200), then process the event asynchronously (e.g., push it onto a queue or background worker). This keeps acknowledgment fast while still handling the logic reliably, and it prevents retries and duplicate handling.
✅ A. Reply with a 200-level HTTP response quickly –Z A prompt HTTP 200 acknowledgment (within 3 seconds) prevents Slack from retrying and keeps the subscription healthy.
❌ Why Other Options Are Incorrect:
B. Send back a Block Kit payload – The acknowledgment doesn't require a Block Kit payload; Slack just needs a 200. Sending UI content isn't the way to acknowledge events.
C. Log out the user – Logging out a user has nothing to do with event acknowledgment and is not part of the Events API flow.
D. Request a new OAuth scope – Scopes are configured ahead of time and granted via OAuth; you can't request a scope as an event acknowledgment.
References:
Slack API Docs – Events API / Acknowledging events – States apps must respond with HTTP 200 within 3 seconds to avoid retries.
Slack API Docs – Retries & event subscription health – Explains retry behavior and that repeated failures can disable event subscriptions.
When Slack sends an event to your app's Request URL via the Events API, your app must acknowledge receipt quickly by returning an HTTP 200-level response — within 3 seconds. This fast acknowledgment tells Slack "I received the event," so Slack doesn't consider the delivery failed.
This is crucial because:
If your app doesn't respond within 3 seconds, Slack treats it as a failure and retries delivery, which can lead to duplicate processing.
If retries keep failing (Slack retries up to a few times over a period), Slack may disable your event subscriptions and notify you, breaking your app.
The recommended pattern is to acknowledge immediately (return 200), then process the event asynchronously (e.g., push it onto a queue or background worker). This keeps acknowledgment fast while still handling the logic reliably, and it prevents retries and duplicate handling.
✅ A. Reply with a 200-level HTTP response quickly –Z A prompt HTTP 200 acknowledgment (within 3 seconds) prevents Slack from retrying and keeps the subscription healthy.
❌ Why Other Options Are Incorrect:
B. Send back a Block Kit payload – The acknowledgment doesn't require a Block Kit payload; Slack just needs a 200. Sending UI content isn't the way to acknowledge events.
C. Log out the user – Logging out a user has nothing to do with event acknowledgment and is not part of the Events API flow.
D. Request a new OAuth scope – Scopes are configured ahead of time and granted via OAuth; you can't request a scope as an event acknowledgment.
References:
Slack API Docs – Events API / Acknowledging events – States apps must respond with HTTP 200 within 3 seconds to avoid retries.
Slack API Docs – Retries & event subscription health – Explains retry behavior and that repeated failures can disable event subscriptions.