Every Slack app starts with a question: what does it need access to? Scopes define the answer: each one grants a specific ability, like reading channels or posting messages. But how do scopes work and what is the best way to use them in your app?

How scopes work

Each scope maps to one or more API methods. If your app hasn’t been granted the right scope, the API returns a missing_scope error.

Scopes come in two types: bot scopes and user scopes. Bot scopes belong to your app and remain active for the workspace regardless of who installed it. User scopes are tied to the person who authorized your app. When your app uses them, it acts as that user.

The scopes your app needs are defined in the app manifest or through the app settings dashboard. Once defined, they will need to be updated if the needed permissions change. 

From these definitions, your app requests scopes during the OAuth authorization flow. For transparency, the authorization flow provides the full list of requested permissions. This lets the user understand what your app is asking access for. Once granted, your app holds those scopes until it’s uninstalled or the scopes are revoked.

Scope names follow a resource:action pattern, like channels:read (list channels) or chat:write (post messages). This makes it possible to request narrow access to exactly what you need.

Knowing which scopes exist is one thing. The key is requesting only the ones your app actually uses.

Ask for what you use, nothing more

An app with tightly scoped permissions is more secure, easier to reason about, and more trustworthy to the people who install it. When you add scopes only as your app’s features require them, you avoid accumulating permissions that no longer map to functionality.

This follows the principle of least privilege: request only what you actively use. This will help you from the start and make it easy to audit your app’s scopes later.

The benefits are practical:

• Fewer permissions mean a smaller attack surface if your app is ever compromised.
• A focused scope list makes it easier to debug authorization issues and manage token rotation.
• People are more willing to install an app that asks only for what it needs, and workspaces with app approval policies move faster on apps with fewer, well-justified scopes.
• When you need a new scope later, it’s obvious what changed and why.

Common mistakes

These are the patterns that cause the most problems:

Requesting broad scopes when narrow ones exist. Slack offers granular scopes so you can request only what each feature requires. If your app only reads channel messages, it doesn’t need access to all conversation history.

Carrying over scopes from development. It’s easy to add scopes while building and forget to clean them up before shipping. An audit of your scope list before release catches these.

Requesting scopes “just in case.” A scope should map to a feature your app uses today, not one you plan to build later.

How to audit your scope list

Before you ship or update your app, walk through this checklist:

1. List every scope your app currently requests.

2. For each scope, name the specific feature that uses it.

3. If you can’t name a feature, remove the scope.

4. Check whether a narrower scope exists for any broad permissions you’re using.

This takes a few minutes and can help you catch any scopes that crept in during development.

Slack maintains a complete list of available scopes. You can use it to find the narrowest scope that fits your use case.

If you’re preparing your app for the Slack Marketplace, scopes are one of the first things the review team evaluates. Check out our post on scoping your app for the Slack Marketplace for what the review process looks for and how to make sure your app is ready for general distribution.