For obtaining access/bearer tokens, we support three of RFC-6749's grant flows, plus a custom Bitbucket flow for exchanging JWT tokens for access tokens. Note that Resource Owner Password Credentials Grant (4.3) is no longer supported. Check out our OAuth 2.0 developer documentation for more details.
This section provides the basic OAuth 2.0 information to register your consumer and set up OAuth 2.0 to make API calls.
Create a consumer
OAuth needs a key and secret, together these are know as an OAuth consumer. You can create a consumer on any existing workspace. To create a consumer, do the following:
Select your avatar (Your profile and settings) from the navigation bar at the top of the screen.
Under Recent workspaces, select the workspace that will be accessed using the consumer; or find and open the workspace under All workspaces.
On the sidebar, select Settings to open the Workspace settings.
On the sidebar, under Apps and features, select OAuth consumers.
Click the Add consumer button.
The system requests the following information:
Name: The display name for your consumer. This must be unique within your account. This is required. Description: An optional description of what your consumer does. Callback URL: Required for OAuth 2.0 consumers.
When making requests you can include a call back URL in the request:
If you do include the URL in a request it must be appended to the same URL configured in the consumer. So if your consumer callback URL is example.com/add-on the URL in your request must be something similar to example.com/add-on/function.
If you don't include the URL in the request we redirect to the callback URL in the consumer.
URL: An optional URL where the curious can go to learn more about your cool application.
Click Save. The system generates a key and a secret for you.
Toggle the consumer name to see the generated Key and Secret value for your consumer.
For obtaining access/bearer tokens, we support three of RFC-6749's grant flows, plus a custom Bitbucket flow for exchanging JWT tokens for access tokens through the following URL's:
Scopes are defined on the client/consumer instance. Bitbucket Cloud does not currently support the use of the optional scope parameter on the individual grant requests.
When the scope parameter is provided, Bitbucket will validate that it contains no scopes that were not already present on the client/consumer and fail if additional scopes are requested, but asking for fewer scopes will not affect the resulting access token.
The following scopes are available:
Grants read-only access to all the user's account information.
see all email addresses
Grants the ability to change properties on the user's account.
delete the authorizing user's account
manage the user's groups
manipulate a user's email addresses
change username, display name and avatar
Grants the ability to get a list of teams of which the current user is a member. This is covered by the teams endpoint.
information about all the groups and teams I am a member or admin of
Grants (implies) the team scope and adds the ability to manage the teams on which the authorizing user is an administrator.
manage team permissions
Grants read access to all the repositories to which the authorizing user has access. Note that this scope does not give access to a repository's pull requests.
access to the repository's source code
clone over https://
access the file browsing API
download zip archives of the repository's contents
the ability to view and use the issue tracker on any repository (created issues, comment, vote, etc)
the ability to view and use the wiki on any repository (create/edit pages)
Grants (implies) the repository scope and adds write access to all the repositories to which the authorizing user has access. No distinction is made between public or private repositories. This scope alone does not give access to the pull requests API.
push access over https
Grants admin access to all the repositories to which the authorizing user has access. No distinction is made between public or private repositories. This scope does not imply repository or repository:write. It gives access to the admin features of a repository only, not direct access to its contents. Of course it can be (mis)used to grant read access to another user account who can then clone the repository, but repositories that need to read or write source code would also request explicit read or write. This scope comes with access to the following functionality:
view and manipulate committer mappings
list and edit deploy keys
ability to delete the repository
view and edit repository permissions
view and edit branch permissions
import and export the issue tracker
enable and disable the issue tracker
list and edit issue tracker version, milestones, and components
enable and disable the wiki
list and edit default reviewers
list and edit repository links (Jira/Bamboo/Custom)
list and edit the repository webhooks
initiate a repository ownership transfer
Grants read access to pull requests and the ability to collaborate on a specific pull request through comments, tasks, and approvals. This scope implies repository, giving read access to the pull request's destination repository.
see and list pull requests
create and resolve tasks
Grants (implies) the pullrequest scope and adds the ability to create, merge and decline pull requests. This scope also implies repository:write, giving write access to the pull request's destination repository. This is necessary to facilitate merging.
merge pull requests
decline pull requests
create pull requests
comment on pull requests
approve pull requests
Grants read access to all the snippets to which the authorizing user has access. No distinction is made between public and private snippets (public snippets are accessible without any form of authentication).
view any snippet
create snippet comments
Grants write access to all the snippets the authorizing user can edit. No distinction is made between public and private snippets (public snippets are accessible without any form of authentication). This implies the Snippet Read scope which does not need to be requested separately.
Grants the ability to interact with an issue tracker as if you had no other repository access. This scope does not imply any other scopes and does not give implicit access to the repository the issue is attached to.
view, list and search issues
create new issues
comment on issues
vote for issues
Grants (implies) the issue scope and adds the ability to transition and delete issues. This scope does not imply any other scopes and does not give implicit access to the repository to which the issue is attached.
Grants access to wikis. No distinction is made between read and write as wikis are always editable by anyone. This scope does not imply any other scopes and does not give implicit access to the repository the wiki is attached to.
push to wikis
Grants the ability to see the user's primary email address. This should make it easier to use Bitbucket Cloud as a login provider to add-ons or external applications.
This scope gives read access to existing webhook subscriptions on all resources you can access, without needing further scopes. This scope is required for any webhook related operation.
list webhook subscriptions on any accessible repository, workspace, or snippet
create/update/delete webhook subscriptions
This means that a client can list all existing webhook subscriptions on repository foo/bar (assuming the principal user has access to this repository). The additional repository scope is not required for this.
Likewise, existing webhook subscriptions for a repository's issue tracker can be retrieved without holding the issue scope. All that is required is the webhook scope.
However, to create a webhook for issue:created, the client will need to have both the webhook and the issue scope.
Cloning a repository with an access token
Since add-ons will not be able to upload their own SSH keys to clone with, access tokens can be used as Basic HTTP Auth credentials to clone securely over HTTPS.