Question
Slack App Manifest for repeatable dev environments: choosing least-privilege scopes and Socket Mode vs Events API
Ash Maple
0 reputation · 26 Feb 2022, 18:51 UTC
26.7K views1
Loading…
0 reputation · 26 Feb 2022, 18:51 UTC
I am defining a Slack app entirely through an App Manifest (YAML) so the same bot user, event subscriptions, and OAuth scopes can be recreated across disposable workspaces for development and CI. The manifest itself is under version control, while the bot token, app-level token, and signing secret are injected per environment.
Two parts of the configuration are not settled. First, the scope set: I want a least-privilege baseline of granular bot scopes, but I am unsure how to confirm that the scopes granted at install time actually match the manifest, since workspace consent can alter the effective permissions. Second, event delivery: Socket Mode avoids needing a public HTTPS Request URL and the URL verification challenge, which suits laptops and containers, but it changes scaling and egress assumptions compared with a public Events API callback.
35275 reputation · 26 Feb 2022, 20:14 UTC
To maintain repeatable development environments, your Slack App Manifest should define the desired state of the bot, while environment-specific secrets (tokens and signing secrets) are injected at runtime. Below are the resolutions for your configuration decisions.
For an app that reads channel messages and posts replies, use the following granular bot scopes in your manifest under oauth_config.scopes.bot:
slackchat:write: Allows the bot to send messages.channels:read: Allows the bot to view public channel metadata and history.groups:read: Allows the bot to view private channel metadata and history.app_mentions:read: Necessary if the bot must trigger specifically on mentions.Because workspace administrators can deselect scopes during the OAuth consent flow, the manifest represents the requested permissions, not necessarily the granted ones. To verify the actual permissions after installation, call the auth.test API method using the bot token:
curl -H "Authorization: Bearer xoxb-your-token" https://slack.com/api/auth.testThe response contains a scope field. Compare this string against your manifest's scope list to ensure the bot has the required permissions to function in that specific environment.
For repeatable dev environments, Socket Mode is the recommended default. It eliminates the need for a public HTTPS endpoint and the associated URL verification challenge, making it ideal for local development, containers, and CI pipelines where ingress is restricted.
| Feature | Socket Mode | Events API |
|---|---|---|
| Ingress | None (Outbound WebSocket) | Public HTTPS Request URL |
| Setup | Requires App-Level Token (xapp-) |
Requires Signing Secret + URL |
| Scaling | Connection-based sharding | Horizontal (Load Balancer) |
While a single manifest can technically contain both event_subscriptions.request_url and settings.socket_mode_enabled: true, it is safer to maintain separate manifests per environment (e.g., manifest.dev.yaml and manifest.prod.yaml).
This prevents configuration drift and avoids ambiguity. If both are enabled, Slack typically prefers Socket Mode when a valid app-level token is present, which can lead to "silent" failures if you intend to test the Events API path but the app is defaulting to a WebSocket connection.
Ensure your app-level token is provisioned with the connections:write scope; this is a requirement for Socket Mode but is not listed as a bot scope in the manifest.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.