A notification lands in a channel. Did the app send it, or did a person? 

The answer depends on which token your app used. If it’s a bot token, it’s your app sending it. If it’s a user token, it indicates that a user’s actions triggered the event. 

Simply, the token your app uses identifies the source of the action. Understanding the difference between bot and user tokens helps you choose the right one for each feature.

What a token represents

A token ties together the permissions your app has been granted. It tells Slack which permissions apply to the request and what entity is making it.

Bot tokens (which begin with xoxb-) represent the bot associated with your app. They remain active for the workspace regardless of which person installed it. Because the bot isn’t tied to any individual user, it stays active regardless of changes to user accounts. Messages posted with a bot token appear under the app’s name. Events are delivered based on channels the bot has been added to.

User tokens (which begin with xoxp-) let your app act on behalf of a specific workspace member. When your app uses a user token, Slack treats the action as if that person performed it. Messages appear under their name. Channels they can see become channels your app can see through their token.

When to use bot tokens

Bot tokens are the right choice for most functionality. They give your app a stable, independent identity that doesn’t depend on any single user.

Use a bot token when your app:

• Posts messages as itself (notifications, alerts, summaries)
• Responds to slash commands or interactions
• Listens for events in channels the bot has been added to
• Manages its own workflows or scheduled tasks

Because bot tokens persist independently of any user account, they are more reliable for long-running automations. An app built entirely on user tokens breaks when that user is deactivated.

When to use user tokens

Sometimes your app needs to act on someone’s behalf rather than as itself.

Use a user token when your app:

• Posts a message that should appear as the user, not the app
• Reads conversations the bot hasn’t been invited to but the user can see
• Modifies user-specific settings like profile or status
• Accesses resources scoped to that person’s role (like admin-only channels)

User tokens grant access tied to a real person’s identity and permissions, so request them only when a feature genuinely requires it.

How scopes relate to token type

Every scope belongs to either a bot token or a user token. When you define scopes in your app manifest, you assign each one to a token type. The same capability sometimes exists in both forms: chat:write as a bot scope lets your app post as itself, while chat:write as a user scope lets it post as the authorizing user.

An app can use bot token scopes and user token scopes side by side. Most apps rely primarily on bot scopes, adding user scopes only for features that require them. This keeps the permission footprint small and the install prompt clean.

For most features, bot tokens are the right starting point. They keep your app independent and persistent. Reach for user tokens only when a feature needs to appear as a specific person or access resources only that person can see. You can always add user token scopes later if a feature requires them, but the reverse (migrating from user tokens to bot tokens) requires reauthorization from every user.

You’ll configure both through your app manifest and via the Slack App API interface. The linter in the interface can help you use the right scopes for the tokens you define. Even so, you’ll need to determine which your app needs to best do its job with the minimal permissions requested. 

For more information about using scopes effectively, check out our post on Slack’s approach to scopes and how to best use them for a Slack Marketplace app.