Slack drew a scope around what a bot user can see

The conversation

A Slack app that wants to act as a chat participant, rather than only a slash command or a webhook target, registers what Slack calls a bot user. Slack's own documentation, reached from api.slack.com and retrieved 16 September 2026, describes a bot user as the same as a regular app, able to send direct messages, be mentioned by users, post messages or upload files, distinguished mainly by the personality a developer gives it. Installing a bot generates a bot token, imbued, the documentation says, with the bot scope, a permission grant distinct from a human user's own access token. To be told about new messages and other activity, rather than only responding when addressed directly, an app subscribes through what Slack calls the Events API.

What the documents show

Slack's own Events API documentation, at docs.slack.dev, states that the Events API leverages Slack's existing object-driven OAuth scope system to control access to events, meaning an app only receives the categories of activity its granted scopes cover. An app chooses how those events arrive: either through Socket Mode, or by designating a public HTTP endpoint the app listens on, and the documentation requires that the app respond to an event with an HTTP success code within three seconds. A bot user can subscribe to events on its own behalf, seeing activity the documentation calls perspectival to that bot user, rather than every event in a workspace. The same page states that beginning 31 March 2025, Slack would discontinue support for legacy custom bots, meaning the bot-user model described there is explicitly a legacy one.

The system boundary

The scope system is the boundary Slack's own documentation draws around a bot: a bot token can only reach the range of workspace data and actions its granted scopes cover, and the Events API delivers only the categories of activity a workspace has agreed to expose to that app. A bot user is not a privileged observer of everything happening in a workspace; it is a distinct, permissioned identity that, like a human member, sees and acts within limits a workspace administrator approved at installation time.

Where it fails

Because Slack's documentation explicitly marks the classic bot-user and bot-scope model as legacy, with a stated discontinuation date for legacy custom bots, a builder reading an older tutorial about Slack bots may be looking at a model Slack itself is retiring rather than the one a new app should use.

• Does a given integration rely on the legacy bot-scope model the documentation marks for discontinuation, or on a current app-scope configuration?
• Which specific event types is the app actually subscribed to, and does that match what the bot's logic assumes it will be told about?
• What happens if the app's endpoint cannot answer within the required three seconds, and has that failure path been tested under real load?

The consistent thread across Slack's own pages is that a bot's reach into a workspace is defined by explicit, auditable scopes and subscriptions, not by the bot's own code deciding what it can see or do.