Access tokens

Access tokens are the keys to the Slack platform. Tokens tie together all the scopes and permissions your app has obtained, allowing it to read, write, and interact.

There are multiple types of access token available. The token types are suited for different functionality, and certain scopes are unique to a particular token type.

Read on to learn about the different access token types.

Token types

Bot tokens

The ideal token type for most apps, with a granular permission model to request only the scopes you need.

User tokens

These tokens allow you to work directly on behalf of users, when required.

App-level tokens

Special tokens used with specific APIs that related to the app across all organizations it's installed in.

Configuration tokens

Special per-workspace tokens used with App Manifest APIs to create and configure Slack apps.

Current token types

Bot tokens

Bot tokens represent a bot associated with the app installed in a workspace. Unlike user tokens, they're not tied to a user's identity; they're just tied to your app.

Since acting independently allows your app to stay installed even when an installing user is deactivated, using bot tokens is usually for the best.

Check out the guide to creating Slack apps with bot tokens for more info.

  • Bot token strings begin with xoxb-
  • New bot users can request individual scopes, similar to user tokens.

User tokens

User tokens represent workspace members. They are issued for the user who installed the app and for users who authenticate the app. When your app asks for OAuth scopes, they are applied to user tokens. You can use these tokens to take actions on behalf of users.

  • User token strings begin with xoxp-
  • User tokens gain the "old world" resource-based OAuth scopes requested in the installation process (example: asking for channels:history grants a user token access to conversations.history for any public channel)
  • User tokens represent the same access a user has to a workspace -- the channels, conversations, users, reactions, etc. they can see
  • Write actions with user tokens are performed as if by the user themselves

App-level tokens

App-level tokens represent your app across organizations, including installations by all individual users on all workspaces in a given organization.

  • App-level token strings begin with xapp-. We sometimes refer to them as "zap!" tokens.

These tokens give you the ability to handle things that relate to your app as a whole, like listing all the authorizations an event is visible to.

Configuration tokens

App configuration tokens (or config tokens for short) are solely used to create and configure Slack apps using our App Manifest APIs.

Each config token is unique to a user and a workspace, but not an app. This means you can manage the configuration of any of your apps in a single development workspace, with just one config token.

Legacy token types

Legacy bot tokens

These umbrella bot tokens, obtained through an older OAuth flow, should only be used in a few special cases like connecting to the Real Time Messaging API.

Workspace tokens

Legacy workspace apps will be fully deprecated in August 2021. Don't use this token type for new apps.

Legacy tokens

These legacy tokens, scopes, and methods are better left to the past.

The previous generation

Legacy bot tokens

Legacy bot tokens requested an umbrella bot scope with many different permissions included within it.

We have now moved away from this umbrella permission model, and instead recommend you use newer, granular bot tokens. Newer platform features will no longer be supported with the legacy bot token.

Here is some information for those still using legacy bot tokens:

  • Legacy bot tokens can't have resource-based OAuth scopes added to them, any scopes other than bot requested during the OAuth installation flow have no effect on the legacy bot token.
  • Revoking an legacy bot token with auth.revoke does not uninstall the bot user. A new token may be obtained via OAuth or, for internal integrations, your app management console.

Workspace tokens

The developer preview for workspace apps has ended. We're taking the components of workspace apps and breaking them apart: applying them in phases to existing as well as new apps. Read more about the motivation behind ending the preview.

For those who already have an existing app using a workspace token, here's a quick overview on how they work:

  • Workspace access token strings begin with xoxa-2.
  • Workspace refresh token strings begin with xoxr.
  • Access tokens are the only tokens used to call an API method.
  • Use your refresh token to rotate and refresh your access token with no downtime.
  • Bot users and bot user tokens cannot be used in conjunction with workspace tokens.
  • No requests are made on behalf of users with workspace tokens.
  • OAuth scopes negotiated during the OAuth installation process or through the Permissions API are applied directly to your workspace token.

See working with workspace tokens and the Permissions API to learn more.

Legacy tokens

These tokens were associated with legacy custom integrations and early Slack integrations requiring an ambiguous "API token." They were generated using the legacy token generator and are no longer recommended for use. They take on the full operational scope of the user that created them.

If you're building a tool for your own team, we encourage creating an internal integration with only the scopes it needs to work.