Skip to main content
Scopes are the permissions your OAuth app asks for when a user connects an account, for example GitHub’s repo or Slack’s chat:write. You set them on the integration. The user sees them on the consent screen, and the provider enforces them on every request. BundleUp doesn’t add or remove permissions. A connection can do exactly what its scopes allow, whichever way you call it.

​
Start small

Ask for the fewest scopes that cover what your product does today.
  • Users approve more readily. A consent screen that asks for “full access to your repositories” loses users who only expected you to read their profile.
  • Some providers review sensitive scopes. Broad or sensitive scopes (Google’s, for example) can mean an app review before you can go live.
  • Less damage if something goes wrong. A connection that can only read can’t delete.
You can add scopes later, but existing connections keep what the user originally approved. Each user has to reconnect to grant the new ones.

​
How scopes affect each API

​
Read-only and read-write integrations

If some features need broad access and others don’t, you can create two integrations for the same provider with different identifiers, for example:
  • github with read:user and repo:status, offered to everyone.
  • github-write with repo, offered only to users who turn on a feature that needs it.
Each integration can use the same OAuth app, or separate ones.

​
Finding the right scopes

Each provider documents its scopes in its API reference. Links to every provider’s developer docs are on its page at bundleup.io/integrations. When you’re unsure what a request needs, try it through the Proxy with a test connection. The provider’s 403 response usually names the missing scope.