Does Slack re-verify event subscription URLs after app reinstall
0 reputation · 18 Mar 2020, 19:22 UTC
0 reputation · 18 Mar 2020, 19:22 UTC
A Slack app verifies its event subscription endpoint during local development using an ngrok URL. After deployment, the production endpoint differs, and the app is reinstalled in the target workspace.
The goal is to determine whether Slack automatically initiates a new URL verification handshake when an app is reinstalled with a changed event subscription endpoint, or whether an administrator must manually re-enable event subscriptions in the app management dashboard before events are delivered.
Slack's Events API requires the endpoint to return the challenge value within three seconds and present a publicly trusted TLS certificate, but it is unclear whether a reinstall resets the verification state or inherits the prior verified URL. This uncertainty affects whether production deployments can rely on automated provisioning or require manual dashboard steps.
Does Slack trigger automatic re-verification when the event subscription URL changes across app installations? Which dashboard settings control whether event subscriptions remain active after a reinstall? What response does Slack expect if the endpoint is unreachable during the reinstall flow?
35275 reputation · 18 Mar 2020, 19:45 UTC
No. Slack does not automatically initiate a new URL verification handshake when an app is reinstalled with a changed event subscription endpoint. If the Request URL in the app management dashboard was changed from the ngrok development URL to the production endpoint, an administrator must open Event Subscriptions, save the new URL, and complete the challenge-response exchange before Slack delivers events to that URL. If the Request URL was left unchanged, the existing verification remains valid after reinstall and Slack sends no new handshake.
Slack treats the Event Subscriptions Request URL as static configuration associated with the app, not with a specific installation. Reinstalling the app does not reset that configuration. When the URL value is unchanged, Slack considers the prior verification still valid. When the URL value is changed, Slack does not push a verification request to the new endpoint on its own; verification is triggered by saving the URL in the dashboard.
The endpoint must respond to Slack's url_verification request with a JSON body containing the challenge value exactly as received, within three seconds, over HTTPS with a publicly trusted TLS certificate. If the endpoint is unreachable, returns the wrong value, or uses a self-signed or expired certificate, Slack marks the URL unverified and does not deliver events.
url_verification event to the new endpoint.challenge value and that the dashboard shows the URL as verified.Slack does not deliver events to an unverified URL. An unreachable endpoint during the verification handshake leaves the URL in an unverified state. Reinstalling the app again does not retry verification automatically; save the URL again once the endpoint is reachable.
Use a temporary test endpoint that logs incoming POST bodies and echoes the challenge string. Confirm a valid TLS certificate is installed, then save the URL in the dashboard and check for the url_verification request in the logs. Inspect the Event Subscriptions page to confirm the verification status for the configured URL.
Was the Request URL field in the Slack app dashboard updated to the production endpoint before or after the reinstall? This determines whether a new verification handshake is required at all.
This answer assumes a standard Slack app using the Events API with dashboard-managed Event Subscriptions. It does not cover manifest-based app distribution or workspace-specific overrides that may alter the flow. Rate limiting on repeated URL saves is possible but not detailed here.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.