Bitbucket

Overview

Code against the Bitbucket API to automate simple tasks, embed Bitbucket data into your own site, build mobile or desktop apps, or even add custom UI add-ons into Bitbucket itself using the Connect framework.

Setting up Bitbucket

Create an access token

To get started you'll need a Bitbucket access token:

1. Follow one of the following guides to create an access token:
   • Create a Repository Access Token
   • Create a Project Access Token
   • Create a Workspace Access Token
2. Copy the token to configure your integration's connection

Learn more about Bitbucket API Authentication

Add integration

Once you have an access token, you're ready to set up your Superblocks integration.

1. In the web app, navigate to the Integrations page
2. Click on the Bitbucket tile
3. Name the integration
4. Paste your credentials into the relevant fields
5. Optionally, add more configurations to set credentials for different environments
6. Click Create

tip

Bitbucket connected!
Now you can use Bitbucket in any Application, Workflow, or Scheduled Job.

Use Bitbucket in APIs

Once your Bitbucket integration is created, you can start calling Bitbucket actions in Superblocks APIs.

Bitbucket actions are REST requests. To learn more about REST requests in Superblocks, see the Building REST requests guide.

Supported actions

Get a webhook resource

Returns the webhook resource or subject types on which webhooks can be registered. Each resource/subject type contains an `events` link that returns the paginated list of specific events each individual subject type can emit. This endpoint is publicly accessible and does not require authentication or scopes.

List subscribable webhook types

Returns a paginated list of all valid webhook events for the specified entity. **The team and user webhooks are deprecated, and you should use workspace instead. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).** This is public data that does not require any scopes or authentication. NOTE: The example response is a truncated response object for the `workspace` `subject_type`. We return the same structure for the other `subject_type` objects.

List pull requests for a user

Returns all pull requests authored by the specified user. By default only open pull requests are returned. This can be controlled using the `state` query parameter. To retrieve pull requests that are in one of multiple states, repeat the `state` parameter for each individual state. This endpoint also supports filtering and sorting of the results. See [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) for more details.

List public repositories

Returns a paginated list of all public repositories. This endpoint also supports filtering and sorting of the results. See [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) for more details.

List repositories in a workspace

Returns a paginated list of all repositories owned by the specified workspace. The result can be narrowed down based on the authenticated user's role. E.g. with `?role=contributor`, only those repositories that the authenticated user has write access to are returned (this includes any repo the user is an admin on, as that implies write access). This endpoint also supports filtering and sorting of the results. See [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) for more details.

Get a repository

Returns the object describing this repository.

Create a repository

Creates a new repository. Note: In order to set the project for the newly created repository, pass in either the project key or the project UUID as part of the request body as shown in the examples below: or The project must be assigned for all repositories. If the project is not provided, the repository is automatically assigned to the oldest project in the workspace. Note: In the examples above, the workspace ID `teamsinspace`, and/or the repository name `hablanding` can be replaced by UUIDs.

Update a repository

Since this endpoint can be used to both update and to create a repository, the request body depends on the intent. #### Creation See the POST documentation for the repository endpoint for an example of the request body. #### Update Note: Changing the `name` of the repository will cause the location to be changed. This is because the URL of the repo is derived from the name (a process called slugification). In such a scenario, it is possible for the request to fail if the newly created slug conflicts with an existing repository's slug. But if there is no conflict, the new location will be returned in the `Location` header of the response.

Delete a repository

Deletes the repository. This is an irreversible operation. This does not affect its forks.

List branch restrictions

Returns a paginated list of all branch restrictions on the repository.

Create a branch restriction rule

Creates a new branch restriction rule for a repository. `kind` describes what will be restricted. Allowed values include: `push`, `force`, `delete`, `restrict_merges`, `require_tasks_to_be_completed`, `require_approvals_to_merge`, `require_default_reviewer_approvals_to_merge`, `require_no_changes_requested`, `require_passing_builds_to_merge`, `require_commits_behind`, `reset_pullrequest_approvals_on_change`, `smart_reset_pullrequest_approvals`, `reset_pullrequest_changes_requested_on_change`, `require_all_dependencies_merged`, `enforce_merge_checks`, and `allow_auto_merge_when_builds_pass`. Different kinds of branch restrictions have different requirements: * `push` and `restrict_merges` require `users` and `groups` to be specified. Empty lists are allowed, in which case permission is denied for everybody. The restriction applies to all branches that match. There are two ways to match a branch. It is configured in `branch_match_kind`: 1. `glob`: Matches a branch against the `pattern`. A `'*'` in `pattern` will expand to match zero or more characters, and every other character matches itself. For example, `'foo*'` will match `'foo'` and `'foobar'`, but not `'barfoo'`. `'*'` will match all branches. 2. `branching_model`: Matches a branch against the repository's branching model. The `branch_type` controls the type of branch to match. Allowed values include: `production`, `development`, `bugfix`, `release`, `feature` and `hotfix`. The combination of `kind` and match must be unique. This means that two `glob` restrictions in a repository cannot have the same `kind` and `pattern`. Additionally, two `branching_model` restrictions in a repository cannot have the same `kind` and `branch_type`. `users` and `groups` are lists of users and groups that are except from the restriction. They can only be configured in `push` and `restrict_merges` restrictions. The `push` restriction stops a user pushing to matching branches unless that user is in `users` or is a member of a group in `groups`. The `restrict_merges` stops a user merging pull requests to matching branches unless that user is in `users` or is a member of a group in `groups`. Adding new users or groups to an existing restriction should be done via `PUT`. Note that branch restrictions with overlapping matchers is allowed, but the resulting behavior may be surprising.

Get a branch restriction rule

Returns a specific branch restriction rule.

Update a branch restriction rule

Updates an existing branch restriction rule. Fields not present in the request body are ignored. See [`POST`](/cloud/bitbucket/rest/api-group-branch-restrictions/#api-repositories-workspace-repo-slug-branch-restrictions-post) for details.

Delete a branch restriction rule

Deletes an existing branch restriction rule.

Get the branching model for a repository

Return the branching model as applied to the repository. This view is read-only. The branching model settings can be changed using the [settings](#api-repositories-workspace-repo-slug-branching-model-settings-get) API. The returned object: 1. Always has a `development` property. `development.branch` contains the actual repository branch object that is considered to be the `development` branch. `development.branch` will not be present if it does not exist. 2. Might have a `production` property. `production` will not be present when `production` is disabled. `production.branch` contains the actual branch object that is considered to be the `production` branch. `production.branch` will not be present if it does not exist. 3. Always has a `branch_types` array which contains all enabled branch types.

Get the branching model config for a repository

Return the branching model configuration for a repository. The returned object: 1. Always has a `development` property for the development branch. 2. Always a `production` property for the production branch. The production branch can be disabled. 3. The `branch_types` contains all the branch types. This is the raw configuration for the branching model. A client wishing to see the branching model with its actual current branches may find the [active model API](/cloud/bitbucket/rest/api-group-branching-model/#api-repositories-workspace-repo-slug-branching-model-get) more useful.

Update the branching model config for a repository

Update the branching model configuration for a repository. The `development` branch can be configured to a specific branch or to track the main branch. When set to a specific branch it must currently exist. Only the passed properties will be updated. The properties not passed will be left unchanged. A request without a `development` property will leave the development branch unchanged. It is possible for the `development` branch to be invalid. This happens when it points at a specific branch that has been deleted. This is indicated in the `is_valid` field for the branch. It is not possible to update the settings for `development` if that would leave the branch in an invalid state. Such a request will be rejected. The `production` branch can be a specific branch, the main branch or disabled. When set to a specific branch it must currently exist. The `enabled` property can be used to enable (`true`) or disable (`false`) it. Only the passed properties will be updated. The properties not passed will be left unchanged. A request without a `production` property will leave the production branch unchanged. It is possible for the `production` branch to be invalid. This happens when it points at a specific branch that has been deleted. This is indicated in the `is_valid` field for the branch. A request that would leave `production` enabled and invalid will be rejected. It is possible to update `production` and make it invalid if it would also be left disabled. The `branch_types` property contains the branch types to be updated. Only the branch types passed will be updated. All updates will be rejected if it would leave the branching model in an invalid state. For branch types this means that: 1. The prefixes for all enabled branch types are valid. For example, it is not possible to use '*' inside a Git prefix. 2. A prefix of an enabled branch type must not be a prefix of another enabled branch type. This is to ensure that a branch can be easily classified by its prefix unambiguously. It is possible to store an invalid prefix if that branch type would be left disabled. Only the passed properties will be updated. The properties not passed will be left unchanged. Each branch type must have a `kind` property to identify it. There is currently a side effect when using this API endpoint. If the repository is inheriting branching model settings from its project, updating the branching model for this repository will disable the project setting inheritance. We have deprecated this side effect and will remove it on 1 August 2022.

Get a commit

Returns the specified commit.

Approve a commit

Approve the specified commit as the authenticated user. This operation is only available to users that have explicit access to the repository. In contrast, just the fact that a repository is publicly accessible to users does not give them the ability to approve commits.

Unapprove a commit

Redact the authenticated user's approval of the specified commit. This operation is only available to users that have explicit access to the repository. In contrast, just the fact that a repository is publicly accessible to users does not give them the ability to approve commits.

List a commit's comments

Returns the commit's comments. This includes both global and inline comments. The default sorting is oldest to newest and can be overridden with the `sort` query parameter.

Create comment for a commit

Creates new comment on the specified commit. To post a reply to an existing comment, include the `parent.id` field:

Get a commit comment

Returns the specified commit comment.

Update a commit comment

Used to update the contents of a comment. Only the content of the comment can be updated.

Delete a commit comment

Deletes the specified commit comment. Note that deleting comments that have visible replies that point to them will not really delete the resource. This is to retain the integrity of the original comment tree. Instead, the `deleted` element is set to `true` and the content is blanked out. The comment will continue to be returned by the collections and self endpoints.

Get a commit application property

Retrieve an [application property](/cloud/bitbucket/application-properties/) value stored against a commit.

Update a commit application property

Update an [application property](/cloud/bitbucket/application-properties/) value stored against a commit.

Delete a commit application property

Delete an [application property](/cloud/bitbucket/application-properties/) value stored against a commit.

List pull requests that contain a commit

Returns a paginated list of all pull requests as part of which this commit was reviewed. Pull Request Commit Links app must be installed first before using this API; installation automatically occurs when 'Go to pull request' is clicked from the web interface for a commit's details.

List reports

Returns a paginated list of Reports linked to this commit.

Get a report

Returns a single Report matching the provided ID.

Create or update a report

Creates or updates a report for the specified commit. To upload a report, make sure to generate an ID that is unique across all reports for that commit. If you want to use an existing id from your own system, we recommend prefixing it with your system's name to avoid collisions, for example, mySystem-001. ### Sample cURL request: ### Possible field values: report_type: SECURITY, COVERAGE, TEST, BUG result: PASSED, FAILED, PENDING data.type: BOOLEAN, DATE, DURATION, LINK, NUMBER, PERCENTAGE, TEXT #### Data field formats | Type Field | Value Field Type | Value Field Display | |:--------------|:------------------|:--------------------| | None/ Omitted | Number, String or Boolean (not an array or object) | Plain text | | BOOLEAN | Boolean | The value will be read as a JSON boolean and displayed as 'Yes' or 'No'. | | DATE | Number | The value will be read as a JSON number in the form of a Unix timestamp (milliseconds) and will be displayed as a relative date if the date is less than one week ago, otherwise it will be displayed as an absolute date. | | DURATION | Number | The value will be read as a JSON number in milliseconds and will be displayed in a human readable duration format. | | LINK | Object: `{"text": "Link text here", "href": "https://link.to.annotation/in/external/tool"}` | The value will be read as a JSON object containing the fields "text" and "href" and will be displayed as a clickable link on the report. | | NUMBER | Number | The value will be read as a JSON number and large numbers will be displayed in a human readable format (e.g. 14.3k). | | PERCENTAGE | Number (between 0 and 100) | The value will be read as a JSON number between 0 and 100 and will be displayed with a percentage sign. | | TEXT | String | The value will be read as a JSON string and will be displayed as-is | Please refer to the [Code Insights documentation](https://confluence.atlassian.com/bitbucket/code-insights-994316785.html) for more information.

Delete a report

Deletes a single Report matching the provided ID.

List annotations

Returns a paginated list of Annotations for a specified report.

Bulk create or update annotations

Bulk upload of annotations. Annotations are individual findings that have been identified as part of a report, for example, a line of code that represents a vulnerability. These annotations can be attached to a specific file and even a specific line in that file, however, that is optional. Annotations are not mandatory and a report can contain up to 1000 annotations. Add the annotations you want to upload as objects in a JSON array and make sure each annotation has the external_id field set to a unique value. If you want to use an existing id from your own system, we recommend prefixing it with your system's name to avoid collisions, for example, mySystem-annotation001. The external id can later be used to identify the report as an alternative to the generated [UUID](https://developer.atlassian.com/bitbucket/api/2/reference/meta/uri-uuid#uuid). You can upload up to 100 annotations per POST request. ### Sample cURL request: ### Possible field values: annotation_type: VULNERABILITY, CODE_SMELL, BUG result: PASSED, FAILED, IGNORED, SKIPPED severity: HIGH, MEDIUM, LOW, CRITICAL Please refer to the [Code Insights documentation](https://confluence.atlassian.com/bitbucket/code-insights-994316785.html) for more information.

Get an annotation

Returns a single Annotation matching the provided ID.

Create or update an annotation

Creates or updates an individual annotation for the specified report. Annotations are individual findings that have been identified as part of a report, for example, a line of code that represents a vulnerability. These annotations can be attached to a specific file and even a specific line in that file, however, that is optional. Annotations are not mandatory and a report can contain up to 1000 annotations. Just as reports, annotation needs to be uploaded with a unique ID that can later be used to identify the report as an alternative to the generated [UUID](https://developer.atlassian.com/bitbucket/api/2/reference/meta/uri-uuid#uuid). If you want to use an existing id from your own system, we recommend prefixing it with your system's name to avoid collisions, for example, mySystem-annotation001. ### Sample cURL request: ### Possible field values: annotation_type: VULNERABILITY, CODE_SMELL, BUG result: PASSED, FAILED, IGNORED, SKIPPED severity: HIGH, MEDIUM, LOW, CRITICAL Please refer to the [Code Insights documentation](https://confluence.atlassian.com/bitbucket/code-insights-994316785.html) for more information.

Delete an annotation

Deletes a single Annotation matching the provided ID.

List commit statuses for a commit

Returns all statuses (e.g. build results) for a specific commit.

Create a build status for a commit

Creates a new build status against the specified commit. If the specified key already exists, the existing status object will be overwritten. When creating a new commit status, you can use a URI template for the URL. Templates are URLs that contain variable names that Bitbucket will evaluate at runtime whenever the URL is displayed anywhere similar to parameter substitution in [Bitbucket Connect](https://developer.atlassian.com/bitbucket/concepts/context-parameters.html). For example, one could use `https://foo.com/builds/{repository.full_name}` which Bitbucket will turn into `https://foo.com/builds/foo/bar` at render time. The context variables available are `repository` and `commit`.

Get a build status for a commit

Returns the specified build status for a commit.

Update a build status for a commit

Used to update the current status of a build status object on the specific commit. This operation can also be used to change other properties of the build status: * `state` * `name` * `description` * `url` * `refname` The `key` cannot be changed.

List commits

These are the repository's commits. They are paginated and returned in reverse chronological order, similar to the output of `git log`. Like these tools, the DAG can be filtered. #### GET /repositories/{workspace}/{repo_slug}/commits/ Returns all commits in the repo in topological order (newest commit first). All branches and tags are included (similar to `git log --all`). #### GET /repositories/{workspace}/{repo_slug}/commits/?exclude=master Returns all commits in the repo that are not on master (similar to `git log --all ^master`). #### GET /repositories/{workspace}/{repo_slug}/commits/?include=foo&include=bar&exclude=fu&exclude=fubar Returns all commits that are on refs `foo` or `bar`, but not on `fu` or `fubar` (similar to `git log foo bar ^fu ^fubar`). An optional `path` parameter can be specified that will limit the results to commits that affect that path. `path` can either be a file or a directory. If a directory is specified, commits are returned that have modified any file in the directory tree rooted by `path`. It is important to note that if the `path` parameter is specified, the commits returned by this endpoint may no longer be a DAG, parent commits that do not modify the path will be omitted from the response. #### GET /repositories/{workspace}/{repo_slug}/commits/?path=README.md&include=foo&include=bar&exclude=master Returns all commits that are on refs `foo` or `bar`, but not on `master` that changed the file README.md. #### GET /repositories/{workspace}/{repo_slug}/commits/?path=src/&include=foo&include=bar&exclude=master Returns all commits that are on refs `foo` or `bar`, but not on `master` that changed to a file in any file in the directory src or its children. Because the response could include a very large number of commits, it is paginated. Follow the 'next' link in the response to navigate to the next page of commits. As with other paginated resources, do not construct your own links. When the include and exclude parameters are more than can fit in a query string, clients can use a `x-www-form-urlencoded` POST instead.

List commits with include/exclude

Identical to `GET /repositories/{workspace}/{repo_slug}/commits`, except that POST allows clients to place the include and exclude parameters in the request body to avoid URL length issues. **Note that this resource does NOT support new commit creation.**

List commits for revision

These are the repository's commits. They are paginated and returned in reverse chronological order, similar to the output of `git log`. Like these tools, the DAG can be filtered. #### GET /repositories/{workspace}/{repo_slug}/commits/master Returns all commits on ref `master` (similar to `git log master`). #### GET /repositories/{workspace}/{repo_slug}/commits/dev?include=foo&exclude=master Returns all commits on ref `dev` or `foo`, except those that are reachable on `master` (similar to `git log dev foo ^master`). An optional `path` parameter can be specified that will limit the results to commits that affect that path. `path` can either be a file or a directory. If a directory is specified, commits are returned that have modified any file in the directory tree rooted by `path`. It is important to note that if the `path` parameter is specified, the commits returned by this endpoint may no longer be a DAG, parent commits that do not modify the path will be omitted from the response. #### GET /repositories/{workspace}/{repo_slug}/commits/dev?path=README.md&include=foo&include=bar&exclude=master Returns all commits that are on refs `dev` or `foo` or `bar`, but not on `master` that changed the file README.md. #### GET /repositories/{workspace}/{repo_slug}/commits/dev?path=src/&include=foo&exclude=master Returns all commits that are on refs `dev` or `foo`, but not on `master` that changed to a file in any file in the directory src or its children. Because the response could include a very large number of commits, it is paginated. Follow the 'next' link in the response to navigate to the next page of commits. As with other paginated resources, do not construct your own links. When the include and exclude parameters are more than can fit in a query string, clients can use a `x-www-form-urlencoded` POST instead.

List commits for revision using include/exclude

Identical to `GET /repositories/{workspace}/{repo_slug}/commits/{revision}`, except that POST allows clients to place the include and exclude parameters in the request body to avoid URL length issues. **Note that this resource does NOT support new commit creation.**

List components

Returns the components that have been defined in the issue tracker. This resource is only available on repositories that have the issue tracker enabled.

Get a component for issues

Returns the specified issue tracker component object.

List default reviewers

Returns the repository's default reviewers. These are the users that are automatically added as reviewers on every new pull request that is created. To obtain the repository's default reviewers as well as the default reviewers inherited from the project, use the [effective-default-reveiwers](#api-repositories-workspace-repo-slug-effective-default-reviewers-get) endpoint.

Get a default reviewer

Returns the specified reviewer. This can be used to test whether a user is among the repository's default reviewers list. A 404 indicates that that specified user is not a default reviewer.

Add a user to the default reviewers

Adds the specified user to the repository's list of default reviewers. This method is idempotent. Adding a user a second time has no effect.

Remove a user from the default reviewers

Removes a default reviewer from the repository.

List deployments

Find deployments

Get a deployment

Retrieve a deployment

List variables for an environment

Find deployment environment level variables.

Create a variable for an environment

Create a deployment environment level variable.

Update a variable for an environment

Update a deployment environment level variable.

Delete a variable for an environment

Delete a deployment environment level variable.

Compare two commits

Produces a raw git-style diff. #### Single commit spec If the `spec` argument to this API is a single commit, the diff is produced against the first parent of the specified commit. #### Two commit spec Two commits separated by `..` may be provided as the `spec`, e.g., `3a8b42..9ff173`. When two commits are provided and the `topic` query parameter is true, this API produces a 2-way three dot diff. This is the diff between source commit and the merge base of the source commit and the destination commit. When the `topic` query param is false, a simple git-style diff is produced. The two commits are interpreted as follows: * First commit: the commit containing the changes we wish to preview * Second commit: the commit representing the state to which we want to compare the first commit * **Note**: This is the opposite of the order used in `git diff`. #### Comparison to patches While similar to patches, diffs: * Don't have a commit header (username, commit message, etc) * Support the optional `path=foo/bar.py` query param to filter the diff to just that one file diff #### Response The raw diff is returned as-is, in whatever encoding the files in the repository use. It is not decoded into unicode. As such, the content-type is `text/plain`.

Compare two commit diff stats

Produces a response in JSON format with a record for every path modified, including information on the type of the change and the number of lines added and removed. #### Single commit spec If the `spec` argument to this API is a single commit, the diff is produced against the first parent of the specified commit. #### Two commit spec Two commits separated by `..` may be provided as the `spec`, e.g., `3a8b42..9ff173`. When two commits are provided and the `topic` query parameter is true, this API produces a 2-way three dot diff. This is the diff between source commit and the merge base of the source commit and the destination commit. When the `topic` query param is false, a simple git-style diff is produced. The two commits are interpreted as follows: * First commit: the commit containing the changes we wish to preview * Second commit: the commit representing the state to which we want to compare the first commit * **Note**: This is the opposite of the order used in `git diff`. #### Sample output

List download artifacts

Returns a list of download links associated with the repository.

Upload a download artifact

Upload new download artifacts. To upload files, perform a `multipart/form-data` POST containing one or more `files` fields: $ echo Hello World > hello.txt $ curl -s -u evzijst -X POST https://api.bitbucket.org/2.0/repositories/evzijst/git-tests/downloads -F files=@hello.txt When a file is uploaded with the same name as an existing artifact, then the existing file will be replaced.

Get a download artifact link

Return a redirect to the contents of a download artifact. This endpoint returns the actual file contents and not the artifact's metadata. $ curl -s -L https://api.bitbucket.org/2.0/repositories/evzijst/git-tests/downloads/hello.txt Hello World

Delete a download artifact

Deletes the specified download artifact from the repository.

Get the effective, or currently applied, branching model for a repository

List effective default reviewers

Returns the repository's effective default reviewers. This includes both default reviewers defined at the repository level as well as those inherited from its project. These are the users that are automatically added as reviewers on every new pull request that is created.

List environments

Find environments

Create an environment

Create an environment.

Get an environment

Retrieve an environment

Delete an environment

Delete an environment

Update an environment

Update an environment

List commits that modified a file

Returns a paginated list of commits that modified the specified file. Commits are returned in reverse chronological order. This is roughly equivalent to the following commands: $ git log --follow --date-order <sha> <path> By default, Bitbucket will follow renames and the path name in the returned entries reflects that. This can be turned off using the `?renames=false` query parameter. Results are returned in descending chronological order by default, and like most endpoints you can [filter and sort](/cloud/bitbucket/rest/intro/#filtering) the response to only provide exactly the data you want. For example, if you wanted to find commits made before 2011-05-18 against a file named `README.rst`, but you only wanted the path and date, your query would look like this: In the response you can see that the file was renamed to `README.rst` by the commit made on 2011-05-16, and was previously named `README.txt`.

List repository forks

Returns a paginated list of all the forks of the specified repository.

Fork a repository

Creates a new fork of the specified repository. #### Forking a repository To create a fork, specify the workspace explicitly as part of the request body: To fork a repository into the same workspace, also specify a new `name`. When you specify a value for `name`, it will also affect the `slug`. The `slug` is reflected in the repository URL of the new fork. It is derived from `name` by substituting non-ASCII characters, removes whitespace, and changes characters to lower case. For example, `My repo` would turn into `my_repo`. You need contributor access to create new forks within a workspace. #### Change the properties of a new fork By default the fork inherits most of its properties from the parent. However, since the optional POST body document follows the normal `repository` JSON schema and you can override the new fork's properties. Properties that can be overridden include: * description * fork_policy * language * mainbranch * is_private (note that a private repo's fork_policy might prohibit the creation of public forks, in which `is_private=False` would fail) * has_issues (to initialize or disable the new repo's issue tracker -- note that the actual contents of the parent repository's issue tracker are not copied during forking) * has_wiki (to initialize or disable the new repo's wiki -- note that the actual contents of the parent repository's wiki are not copied during forking) * project (when forking into a private project, the fork's `is_private` must be `true`) Properties that cannot be modified include: * scm * parent * full_name

List webhooks for a repository

Returns a paginated list of webhooks installed on this repository.

Create a webhook for a repository

Creates a new webhook on the specified repository. Note that this call requires the webhook scope, as well as any scope that applies to the events that the webhook subscribes to. In the example above that means: `webhook`, `repository` and `issue`. Also note that the `url` must properly resolve and cannot be an internal, non-routed address.

Get a webhook for a repository

Returns the webhook with the specified id installed on the specified repository.

Update a webhook for a repository

Updates the specified webhook subscription. The following properties can be mutated: * `description` * `url` * `active` * `events`

Delete a webhook for a repository

Deletes the specified webhook subscription from the given repository.

List issues

Returns the issues in the issue tracker.

Create an issue

Creates a new issue. This call requires authentication. Private repositories or private issue trackers require the caller to authenticate with an account that has appropriate authorization. The authenticated user is used for the issue's `reporter` field.

Export issues

A POST request to this endpoint initiates a new background celery task that archives the repo's issues. For example, you can run: curl -u <username> -X POST http://api.bitbucket.org/2.0/repositories/<owner_username>/<repo_slug>/ issues/export When the job has been accepted, it will return a 202 (Accepted) along with a unique url to this job in the 'Location' response header. This url is the endpoint for where the user can obtain their zip files."

Check issue export status

This endpoint is used to poll for the progress of an issue export job and return the zip file after the job is complete. As long as the job is running, this will return a 200 response with in the response body a description of the current status. After the job has been scheduled, but before it starts executing, this endpoint's response is: { "type": "issue_job_status", "status": "ACCEPTED", "phase": "Initializing", "total": 0, "count": 0, "pct": 0 } Then once it starts running, it becomes: { "type": "issue_job_status", "status": "STARTED", "phase": "Attachments", "total": 15, "count": 11, "pct": 73 } Once the job has successfully completed, it returns a stream of the zip file.

Check issue import status

When using GET, this endpoint reports the status of the current import task. Request example: After the job has been scheduled, but before it starts executing, this endpoint's response is: Once it starts running, it is a 202 response with status STARTED and progress filled. After it is finished, it becomes a 200 response with status SUCCESS or FAILURE.

Import issues

A POST request to this endpoint will import the zip file given by the archive parameter into the repository. All existing issues will be deleted and replaced by the contents of the imported zip file. Imports are done through a multipart/form-data POST. There is one valid and required form field, with the name "archive," which needs to be a file field: When the import job is accepted, here is example output:

Get an issue

Returns the specified issue.

Update an issue

Modifies the issue. This example changes the `title`, `assignee`, `priority` and the `version`. It also removes the value of the `component` from the issue by setting the field to `null`. Any field not present keeps its existing value. Each time an issue is edited in the UI or through the API, an immutable change record is created under the `/issues/123/changes` endpoint. It also has a comment associated with the change.

Delete an issue

Deletes the specified issue. This requires write access to the repository.

List attachments for an issue

Returns all attachments for this issue. This returns the files' meta data. This does not return the files' actual contents. The files are always ordered by their upload date.

Upload an attachment to an issue

Upload new issue attachments. To upload files, perform a `multipart/form-data` POST containing one or more file fields. When a file is uploaded with the same name as an existing attachment, then the existing file will be replaced.

Get attachment for an issue

Returns the contents of the specified file attachment. Note that this endpoint does not return a JSON response, but instead returns a redirect pointing to the actual file that in turn will return the raw contents. The redirect URL contains a one-time token that has a limited lifetime. As a result, the link should not be persisted, stored, or shared.

Delete an attachment for an issue

Deletes an attachment.

List changes on an issue

Returns the list of all changes that have been made to the specified issue. Changes are returned in chronological order with the oldest change first. Each time an issue is edited in the UI or through the API, an immutable change record is created under the `/issues/123/changes` endpoint. It also has a comment associated with the change. Note that this operation is changing significantly, due to privacy changes. See the [announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-changes-gdpr/#changes-to-the-issue-changes-api) for details. Changes support [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) that can be used to search for specific changes. For instance, to see when an issue transitioned to "resolved": This resource is only available on repositories that have the issue tracker enabled. N.B. The `changes.assignee` and `changes.assignee_account_id` fields are not a `user` object. Instead, they contain the raw `username` and `account_id` of the user. This is to protect the integrity of the audit log even after a user account gets deleted. The `changes.assignee` field is deprecated will disappear in the future. Use `changes.assignee_account_id` instead.

Modify the state of an issue

Makes a change to the specified issue. For example, to change an issue's state and assignee, create a new change object that modifies these fields: The above example also includes a custom comment to go alongside the change. This comment will also be visible on the issue page in the UI. The fields of the `changes` object are strings, not objects. This allows for immutable change log records, even after user accounts, milestones, or other objects recorded in a change entry, get renamed or deleted. The `assignee_account_id` field stores the account id. When POSTing a new change and changing the assignee, the client should therefore use the user's account_id in the `changes.assignee_account_id.new` field. This call requires authentication. Private repositories or private issue trackers require the caller to authenticate with an account that has appropriate authorization.

Get issue change object

Returns the specified issue change object. This resource is only available on repositories that have the issue tracker enabled.

List comments on an issue

Returns a paginated list of all comments that were made on the specified issue. The default sorting is oldest to newest and can be overridden with the `sort` query parameter. This endpoint also supports filtering and sorting of the results. See [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) for more details.

Create a comment on an issue

Creates a new issue comment.

Get a comment on an issue

Returns the specified issue comment object.

Update a comment on an issue

Updates the content of the specified issue comment. Note that only the `content.raw` field can be modified.

Delete a comment on an issue

Deletes the specified comment.

Check if current user voted for an issue

Check whether the authenticated user has voted for this issue. A 204 status code indicates that the user has voted, while a 404 implies they haven't.

Vote for an issue

Vote for this issue. To cast your vote, do an empty PUT. The 204 status code indicates that the operation was successful.

Remove vote for an issue

Retract your vote.

Check if current user is watching a issue

Indicated whether or not the authenticated user is watching this issue.

Watch an issue

Start watching this issue. To start watching this issue, do an empty PUT. The 204 status code indicates that the operation was successful.

Stop watching an issue

Stop watching this issue.

Get the common ancestor between two commits

Returns the best common ancestor between two commits, specified in a revspec of 2 commits (e.g. 3a8b42..9ff173). If more than one best common ancestor exists, only one will be returned. It is unspecified which will be returned.

List milestones

Returns the milestones that have been defined in the issue tracker. This resource is only available on repositories that have the issue tracker enabled.

Get a milestone

Returns the specified issue tracker milestone object.

Retrieve the inheritance state for repository settings

Set the inheritance state for repository settings

Get a patch for two commits

Produces a raw patch for a single commit (diffed against its first parent), or a patch-series for a revspec of 2 commits (e.g. `3a8b42..9ff173` where the first commit represents the source and the second commit the destination). In case of the latter (diffing a revspec), a patch series is returned for the commits on the source branch (`3a8b42` and its ancestors in our example). While similar to diffs, patches: * Have a commit header (username, commit message, etc) * Do not support the `path=foo/bar.py` query parameter The raw patch is returned as-is, in whatever encoding the files in the repository use. It is not decoded into unicode. As such, the content-type is `text/plain`.

List explicit group permissions for a repository

Returns a paginated list of explicit group permissions for the given repository. This endpoint does not support BBQL features.

Get an explicit group permission for a repository

Returns the group permission for a given group slug and repository Only users with admin permission for the repository may access this resource. Permissions can be: * `admin` * `write` * `read` * `none`

Update an explicit group permission for a repository

Updates the group permission if it exists. Only users with admin permission for the repository may access this resource. The only authentication method supported for this endpoint is via app passwords. Permissions can be: * `admin` * `write` * `read`

Delete an explicit group permission for a repository

Deletes the repository group permission between the requested repository and group, if one exists. Only users with admin permission for the repository may access this resource.

List explicit user permissions for a repository

Returns a paginated list of explicit user permissions for the given repository. This endpoint does not support BBQL features.

Get an explicit user permission for a repository

Returns the explicit user permission for a given user and repository. Only users with admin permission for the repository may access this resource. Permissions can be: * `admin` * `write` * `read` * `none`

Update an explicit user permission for a repository

Updates the explicit user permission for a given user and repository. The selected user must be a member of the workspace, and cannot be the workspace owner. Only users with admin permission for the repository may access this resource. The only authentication method for this endpoint is via app passwords. Permissions can be: * `admin` * `write` * `read`

Delete an explicit user permission for a repository

Deletes the repository user permission between the requested repository and user, if one exists. Only users with admin permission for the repository may access this resource. The only authentication method for this endpoint is via app passwords.

List pipelines

Find pipelines

Run a pipeline

Endpoint to create and initiate a pipeline. There are a couple of different options to initiate a pipeline, where the payload of the request will determine which type of pipeline will be instantiated. # Trigger a Pipeline for a branch One way to trigger pipelines is by specifying the branch for which you want to trigger a pipeline. The specified branch will be used to determine which pipeline definition from the `bitbucket-pipelines.yml` file will be applied to initiate the pipeline. The pipeline will then do a clone of the repository and checkout the latest revision of the specified branch. # Trigger a Pipeline for a commit on a branch or tag You can initiate a pipeline for a specific commit and in the context of a specified reference (e.g. a branch, tag or bookmark). The specified reference will be used to determine which pipeline definition from the bitbucket-pipelines.yml file will be applied to initiate the pipeline. The pipeline will clone the repository and then do a checkout the specified reference. The following reference types are supported: * `branch` * `named_branch` * `bookmark` * `tag` # Trigger a specific pipeline definition for a commit You can trigger a specific pipeline that is defined in your `bitbucket-pipelines.yml` file for a specific commit. In addition to the commit revision, you specify the type and pattern of the selector that identifies the pipeline definition. The resulting pipeline will then clone the repository and checkout the specified revision. # Trigger a specific pipeline definition for a commit on a branch or tag You can trigger a specific pipeline that is defined in your `bitbucket-pipelines.yml` file for a specific commit in the context of a specified reference. In addition to the commit revision, you specify the type and pattern of the selector that identifies the pipeline definition, as well as the reference information. The resulting pipeline will then clone the repository a checkout the specified reference. # Trigger a custom pipeline with variables In addition to triggering a custom pipeline that is defined in your `bitbucket-pipelines.yml` file as shown in the examples above, you can specify variables that will be available for your build. In the request, provide a list of variables, specifying the following for each variable: key, value, and whether it should be secured or not (this field is optional and defaults to not secured). # Trigger a pull request pipeline You can also initiate a pipeline for a specific pull request.

List caches

Retrieve the repository pipelines caches.

Delete caches

Delete repository cache versions by name.

Delete a cache

Delete a repository cache.

Get cache content URI

Retrieve the URI of the content of the specified cache.

Get a pipeline

Retrieve a specified pipeline

List steps for a pipeline

Find steps for the given pipeline.

Get a step of a pipeline

Retrieve a given step of a pipeline.

Get log file for a step

Retrieve the log file for a given step of a pipeline. This endpoint supports (and encourages!) the use of [HTTP Range requests](https://tools.ietf.org/html/rfc7233) to deal with potentially very large log files.

Get the logs for the build container or a service container for a given step of a pipeline.

Retrieve the log file for a build container or service container. This endpoint supports (and encourages!) the use of [HTTP Range requests](https://tools.ietf.org/html/rfc7233) to deal with potentially very large log files.

Get a summary of test reports for a given step of a pipeline.

Get test cases for a given step of a pipeline.

Get test case reasons (output) for a given test case in a step of a pipeline.

Stop a pipeline

Signal the stop of a pipeline and all of its steps that not have completed yet.

Get configuration

Retrieve the repository pipelines configuration.

Update configuration

Update the pipelines configuration for a repository.

Update the next build number

Update the next build number that should be assigned to a pipeline. The next build number that will be configured has to be strictly higher than the current latest build number for this repository.

List schedules

Retrieve the configured schedules for the given repository.

Create a schedule

Create a schedule for the given repository.

Get a schedule

Retrieve a schedule by its UUID.

Update a schedule

Update a schedule.

Delete a schedule

Delete a schedule.

List executions of a schedule

Retrieve the executions of a given schedule.

List variables for a repository

Find repository level variables.

Create a variable for a repository

Create a repository level variable.

Get a variable for a repository

Retrieve a repository level variable.

Update a variable for a repository

Update a repository level variable.

Delete a variable for a repository

Delete a repository level variable.

Get a repository application property

Retrieve an [application property](/cloud/bitbucket/application-properties/) value stored against a repository.

Update a repository application property

Update an [application property](/cloud/bitbucket/application-properties/) value stored against a repository.

Delete a repository application property

Delete an [application property](/cloud/bitbucket/application-properties/) value stored against a repository.

List pull requests

Returns all pull requests on the specified repository. By default only open pull requests are returned. This can be controlled using the `state` query parameter. To retrieve pull requests that are in one of multiple states, repeat the `state` parameter for each individual state. This endpoint also supports filtering and sorting of the results. See [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) for more details.

Create a pull request

Creates a new pull request where the destination repository is this repository and the author is the authenticated user. The minimum required fields to create a pull request are `title` and `source`, specified by a branch name. If the pull request's `destination` is not specified, it will default to the `repository.mainbranch`. To open a pull request to a different branch, say from a feature branch to a staging branch, specify a `destination` (same format as the `source`): Reviewers can be specified by adding an array of user objects as the `reviewers` property. Other fields: * `description` - a string * `close_source_branch` - boolean that specifies if the source branch should be closed upon merging

List a pull request activity log

Returns a paginated list of the pull request's activity log. This handler serves both a v20 and internal endpoint. The v20 endpoint returns reviewer comments, updates, approvals and request changes. The internal endpoint includes those plus tasks and attachments. Comments created on a file or a line of code have an inline property. Comment example: Updates include a state property of OPEN, MERGED, or DECLINED. Update example: Approval example:

Get a pull request

Returns the specified pull request.

Update a pull request

Mutates the specified pull request. This can be used to change the pull request's branches or description. Only open pull requests can be mutated.

List a pull request activity log

Returns a paginated list of the pull request's activity log. This handler serves both a v20 and internal endpoint. The v20 endpoint returns reviewer comments, updates, approvals and request changes. The internal endpoint includes those plus tasks and attachments. Comments created on a file or a line of code have an inline property. Comment example: Updates include a state property of OPEN, MERGED, or DECLINED. Update example: Approval example:

Approve a pull request

Approve the specified pull request as the authenticated user.

Unapprove a pull request

Redact the authenticated user's approval of the specified pull request.

List comments on a pull request

Returns a paginated list of the pull request's comments. This includes both global, inline comments and replies. The default sorting is oldest to newest and can be overridden with the `sort` query parameter. This endpoint also supports filtering and sorting of the results. See [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) for more details.

Create a comment on a pull request

Creates a new pull request comment. Returns the newly created pull request comment.

Get a comment on a pull request

Returns a specific pull request comment.

Update a comment on a pull request

Updates a specific pull request comment.

Delete a comment on a pull request

Deletes a specific pull request comment.

Resolve a comment thread

Reopen a comment thread

List commits on a pull request

Returns a paginated list of the pull request's commits. These are the commits that are being merged into the destination branch when the pull requests gets accepted.

Decline a pull request

Declines the pull request.

List changes in a pull request

Redirects to the [repository diff](/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-diff-spec-get) with the revspec that corresponds to the pull request.

Get the diff stat for a pull request

Redirects to the [repository diffstat](/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-diffstat-spec-get) with the revspec that corresponds to the pull request.

Merge a pull request

Merges the pull request.

Get the merge task status for a pull request

When merging a pull request takes too long, the client receives a task ID along with a 202 status code. The task ID can be used in a call to this endpoint to check the status of a merge task. If the merge task is not yet finished, a PENDING status will be returned. If the merge was successful, a SUCCESS status will be returned. If the merge task failed, an error will be returned.

Get the patch for a pull request

Redirects to the [repository patch](/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-patch-spec-get) with the revspec that corresponds to pull request.

Request changes for a pull request

Remove change request for a pull request

List commit statuses for a pull request

Returns all statuses (e.g. build results) for the given pull request.

Get a pull request application property

Retrieve an [application property](/cloud/bitbucket/application-properties/) value stored against a pull request.

Update a pull request application property

Update an [application property](/cloud/bitbucket/application-properties/) value stored against a pull request.

Delete a pull request application property

Delete an [application property](/cloud/bitbucket/application-properties/) value stored against a pull request.

List branches and tags

Returns the branches and tags in the repository. By default, results will be in the order the underlying source control system returns them and identical to the ordering one sees when running "$ git show-ref". Note that this follows simple lexical ordering of the ref names. This can be undesirable as it does apply any natural sorting semantics, meaning for instance that refs are sorted ["branch1", "branch10", "branch2", "v10", "v11", "v9"] instead of ["branch1", "branch2", "branch10", "v9", "v10", "v11"]. Sorting can be changed using the ?sort= query parameter. When using ?sort=name to explicitly sort on ref name, Bitbucket will apply natural sorting and interpret numerical values as numbers instead of strings.

List open branches

Returns a list of all open branches within the specified repository. Results will be in the order the source control manager returns them. Branches support [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) that can be used to search for specific branches. For instance, to find all branches that have "stab" in their name: By default, results will be in the order the underlying source control system returns them and identical to the ordering one sees when running "$ git branch --list". Note that this follows simple lexical ordering of the ref names. This can be undesirable as it does apply any natural sorting semantics, meaning for instance that tags are sorted ["v10", "v11", "v9"] instead of ["v9", "v10", "v11"]. Sorting can be changed using the ?q= query parameter. When using ?q=name to explicitly sort on ref name, Bitbucket will apply natural sorting and interpret numerical values as numbers instead of strings.

Create a branch

Creates a new branch in the specified repository. The payload of the POST should consist of a JSON document that contains the name of the tag and the target hash. This call requires authentication. Private repositories require the caller to authenticate with an account that has appropriate authorization. The branch name should not include any prefixes (e.g. refs/heads). This endpoint does support using short hash prefixes for the commit hash, but it may return a 400 response if the provided prefix is ambiguous. Using a full commit hash is the preferred approach.

Get a branch

Returns a branch object within the specified repository. This call requires authentication. Private repositories require the caller to authenticate with an account that has appropriate authorization. For Git, the branch name should not include any prefixes (e.g. refs/heads).

Delete a branch

Delete a branch in the specified repository. The main branch is not allowed to be deleted and will return a 400 response. The branch name should not include any prefixes (e.g. refs/heads).

List tags

Returns the tags in the repository. By default, results will be in the order the underlying source control system returns them and identical to the ordering one sees when running "$ git tag --list". Note that this follows simple lexical ordering of the ref names. This can be undesirable as it does apply any natural sorting semantics, meaning for instance that tags are sorted ["v10", "v11", "v9"] instead of ["v9", "v10", "v11"]. Sorting can be changed using the ?sort= query parameter. When using ?sort=name to explicitly sort on ref name, Bitbucket will apply natural sorting and interpret numerical values as numbers instead of strings.

Create a tag

Creates a new tag in the specified repository. The payload of the POST should consist of a JSON document that contains the name of the tag and the target hash. This endpoint does support using short hash prefixes for the commit hash, but it may return a 400 response if the provided prefix is ambiguous. Using a full commit hash is the preferred approach.

Get a tag

Returns the specified tag.

Delete a tag

Delete a tag in the specified repository. The tag name should not include any prefixes (e.g. refs/tags).

Get the root directory of the main branch

This endpoint redirects the client to the directory listing of the root directory on the main branch. This is equivalent to directly hitting [/2.0/repositories/{username}/{repo_slug}/src/{commit}/{path}](src/%7Bcommit%7D/%7Bpath%7D) without having to know the name or SHA1 of the repo's main branch. To create new commits, [POST to this endpoint](#post)

Create a commit by uploading a file

This endpoint is used to create new commits in the repository by uploading files. To add a new file to a repository: This will create a new commit on top of the main branch, inheriting the contents of the main branch, but adding (or overwriting) the `image.png` file to the repository in the `/repo/path/to` directory. To create a commit that deletes files, use the `files` parameter: You can add/modify/delete multiple files in a request. Rename/move a file by deleting the old path and adding the content at the new path. This endpoint accepts `multipart/form-data` (as in the examples above), as well as `application/x-www-form-urlencoded`. Note: `multipart/form-data` is currently not supported by Forge apps for this API. #### multipart/form-data A `multipart/form-data` post contains a series of "form fields" that identify both the individual files that are being uploaded, as well as additional, optional meta data. Files are uploaded in file form fields (those that have a `Content-Disposition` parameter) whose field names point to the remote path in the repository where the file should be stored. Path field names are always interpreted to be absolute from the root of the repository, regardless whether the client uses a leading slash (as the above `curl` example did). File contents are treated as bytes and are not decoded as text. The commit message, as well as other non-file meta data for the request, is sent along as normal form field elements. Meta data fields share the same namespace as the file objects. For `multipart/form-data` bodies that should not lead to any ambiguity, as the `Content-Disposition` header will contain the `filename` parameter to distinguish between a file named "message" and the commit message field. #### application/x-www-form-urlencoded It is also possible to upload new files using a simple `application/x-www-form-urlencoded` POST. This can be convenient when uploading pure text files: There could be a field name clash if a client were to upload a file named "message", as this filename clashes with the meta data property for the commit message. To avoid this and to upload files whose names clash with the meta data properties, use a leading slash for the files, e.g. `curl --data-urlencode "/message=file contents"`. When an explicit slash is omitted for a file whose path matches that of a meta data parameter, then it is interpreted as meta data, not as a file. #### Executables and links While this API aims to facilitate the most common use cases, it is possible to perform some more advanced operations like creating a new symlink in the repository, or creating an executable file. Files can be supplied with a `x-attributes` value in the `Content-Disposition` header. For example, to upload an executable file, as well as create a symlink from `README.txt` to `README`: Links are files that contain the target path and have `x-attributes:"link"` set. When overwriting links with files, or vice versa, the newly uploaded file determines both the new contents, as well as the attributes. That means uploading a file without specifying `x-attributes="link"` will create a regular file, even if the parent commit hosted a symlink at the same path. The same applies to executables. When modifying an existing executable file, the form-data file element must include `x-attributes="executable"` in order to preserve the executable status of the file. Note that this API does not support the creation or manipulation of subrepos / submodules.

Get file or directory contents

This endpoints is used to retrieve the contents of a single file, or the contents of a directory at a specified revision. #### Raw file contents When `path` points to a file, this endpoint returns the raw contents. The response's Content-Type is derived from the filename extension (not from the contents). The file contents are not processed and no character encoding/recoding is performed and as a result no character encoding is included as part of the Content-Type. The `Content-Disposition` header will be "attachment" to prevent browsers from running executable files. If the file is managed by LFS, then a 301 redirect pointing to Atlassian's media services platform is returned. The response includes an ETag that is based on the contents of the file and its attributes. This means that an empty `__init__.py` always returns the same ETag, regardless on the directory it lives in, or the commit it is on. #### File meta data When the request for a file path includes the query parameter `?format=meta`, instead of returning the file's raw contents, Bitbucket instead returns the JSON object describing the file's properties: File objects contain an `attributes` element that contains a list of possible modifiers. Currently defined values are: * `link` -- indicates that the entry is a symbolic link. The contents of the file represent the path the link points to. * `executable` -- indicates that the file has the executable bit set. * `subrepository` -- indicates that the entry points to a submodule or subrepo. The contents of the file is the SHA1 of the repository pointed to. * `binary` -- indicates whether Bitbucket thinks the file is binary. This endpoint can provide an alternative to how a HEAD request can be used to check for the existence of a file, or a file's size without incurring the overhead of receiving its full contents. #### Directory listings When `path` points to a directory instead of a file, the response is a paginated list of directory and file objects in the same order as the underlying SCM system would return them. For example: When listing the contents of the repo's root directory, the use of a trailing slash at the end of the URL is required. The response by default is not recursive, meaning that only the direct contents of a path are returned. The response does not recurse down into subdirectories. In order to "walk" the entire directory tree, the client can either parse each response and follow the `self` links of each `commit_directory` object, or can specify a `max_depth` to recurse to. The max_depth parameter will do a breadth-first search to return the contents of the subdirectories up to the depth specified. Breadth-first search was chosen as it leads to the least amount of file system operations for git. If the `max_depth` parameter is specified to be too large, the call will time out and return a 555. Each returned object is either a `commit_file`, or a `commit_directory`, both of which contain a `path` element. This path is the absolute path from the root of the repository. Each object also contains a `commit` object which embeds the commit the file is on. Note that this is merely the commit that was used in the URL. It is *not* the commit that last modified the file. Directory objects have 2 representations. Their `self` link returns the paginated contents of the directory. The `meta` link on the other hand returns the actual `directory` object itself, e.g.: #### Querying, filtering and sorting Like most API endpoints, this API supports the Bitbucket querying/filtering syntax and so you could filter a directory listing to only include entries that match certain criteria. For instance, to list all binary files over 1kb use the expression: `size > 1024 and attributes = "binary"` which after urlencoding yields the query string: `?q=size%3E1024+and+attributes%3D%22binary%22` To change the ordering of the response, use the `?sort` parameter: `.../src/eefd5ef/?sort=-size` See [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) for more details.

List defined versions for issues

Returns the versions that have been defined in the issue tracker. This resource is only available on repositories that have the issue tracker enabled.

Get a defined version for issues

Returns the specified issue tracker version object.

List repositories watchers

Returns a paginated list of all the watchers on the specified repository.

List snippets

Returns all snippets. Like pull requests, repositories and workspaces, the full set of snippets is defined by what the current user has access to. This includes all snippets owned by any of the workspaces the user is a member of, or snippets by other users that the current user is either watching or has collaborated on (for instance by commenting on it). To limit the set of returned snippets, apply the `?role=[owner|contributor|member]` query parameter where the roles are defined as follows: * `owner`: all snippets owned by the current user * `contributor`: all snippets owned by, or watched by the current user * `member`: created in a workspaces or watched by the current user When no role is specified, all public snippets are returned, as well as all privately owned snippets watched or commented on. The returned response is a normal paginated JSON list. This endpoint only supports `application/json` responses and no `multipart/form-data` or `multipart/related`. As a result, it is not possible to include the file contents.

Create a snippet

Creates a new snippet under the authenticated user's account. Snippets can contain multiple files. Both text and binary files are supported. The simplest way to create a new snippet from a local file: $ curl -u username:password -X POST https://api.bitbucket.org/2.0/snippets -F file=@image.png Creating snippets through curl has a few limitations and so let's look at a more complicated scenario. Snippets are created with a multipart POST. Both `multipart/form-data` and `multipart/related` are supported. Both allow the creation of snippets with both meta data (title, etc), as well as multiple text and binary files. The main difference is that `multipart/related` can use rich encoding for the meta data (currently JSON). multipart/related (RFC-2387) ---------------------------- This is the most advanced and efficient way to create a paste. POST /2.0/snippets/evzijst HTTP/1.1 Content-Length: 1188 Content-Type: multipart/related; start="snippet"; boundary="===============1438169132528273974==" MIME-Version: 1.0 --===============1438169132528273974== Content-Type: application/json; charset="utf-8" MIME-Version: 1.0 Content-ID: snippet { "title": "My snippet", "is_private": true, "scm": "git", "files": { "foo.txt": {}, "image.png": {} } } --===============1438169132528273974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-ID: "foo.txt" Content-Disposition: attachment; filename="foo.txt" foo --===============1438169132528273974== Content-Type: image/png MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-ID: "image.png" Content-Disposition: attachment; filename="image.png" iVBORw0KGgoAAAANSUhEUgAAABQAAAAoCAYAAAD+MdrbAAABD0lEQVR4Ae3VMUoDQRTG8ccUaW2m TKONFxArJYJamCvkCnZTaa+VnQdJSBFl2SMsLFrEWNjZBZs0JgiL/+KrhhVmJRbCLPx4O+/DT2TB cbblJxf+UWFVVRNsEGAtgvJxnLm2H+A5RQ93uIl+3632PZyl/skjfOn9Gvdwmlcw5aPUwimG+NT5 EnNN036IaZePUuIcK533NVfal7/5yjWeot2z9ta1cAczHEf7I+3J0ws9Cgx0fsOFpmlfwKcWPuBQ 73Oc4FHzBaZ8llq4q1mr5B2mOUCt815qYR8eB1hG2VJ7j35q4RofaH7IG+Xrf/PfJhfmwtfFYoIN AqxFUD6OMxcvkO+UfKfkOyXfKdsv/AYCHMLVkHAFWgAAAABJRU5ErkJggg== --===============1438169132528273974==-- The request contains multiple parts and is structured as follows. The first part is the JSON document that describes the snippet's properties or meta data. It either has to be the first part, or the request's `Content-Type` header must contain the `start` parameter to point to it. The remaining parts are the files of which there can be zero or more. Each file part should contain the `Content-ID` MIME header through which the JSON meta data's `files` element addresses it. The value should be the name of the file. `Content-Disposition` is an optional MIME header. The header's optional `filename` parameter can be used to specify the file name that Bitbucket should use when writing the file to disk. When present, `filename` takes precedence over the value of `Content-ID`. When the JSON body omits the `files` element, the remaining parts are not ignored. Instead, each file is added to the new snippet as if its name was explicitly linked (the use of the `files` elements is mandatory for some operations like deleting or renaming files). multipart/form-data ------------------- The use of JSON for the snippet's meta data is optional. Meta data can also be supplied as regular form fields in a more conventional `multipart/form-data` request: $ curl -X POST -u credentials https://api.bitbucket.org/2.0/snippets -F title="My snippet" -F file=@foo.txt -F file=@image.png POST /2.0/snippets HTTP/1.1 Content-Length: 951 Content-Type: multipart/form-data; boundary=----------------------------63a4b224c59f ------------------------------63a4b224c59f Content-Disposition: form-data; name="file"; filename="foo.txt" Content-Type: text/plain foo ------------------------------63a4b224c59f Content-Disposition: form-data; name="file"; filename="image.png" Content-Type: application/octet-stream ?PNG IHDR?1??I..... ------------------------------63a4b224c59f Content-Disposition: form-data; name="title" My snippet ------------------------------63a4b224c59f-- Here the meta data properties are included as flat, top-level form fields. The file attachments use the `file` field name. To attach multiple files, simply repeat the field. The advantage of `multipart/form-data` over `multipart/related` is that it can be easier to build clients. Essentially all properties are optional, `title` and `files` included. Sharing and Visibility ---------------------- Snippets can be either public (visible to anyone on Bitbucket, as well as anonymous users), or private (visible only to members of the workspace). This is controlled through the snippet's `is_private` element: * **is_private=false** -- everyone, including anonymous users can view the snippet * **is_private=true** -- only workspace members can view the snippet To create the snippet under a workspace, just append the workspace ID to the URL. See [`/2.0/snippets/{workspace}`](/cloud/bitbucket/rest/api-group-snippets/#api-snippets-workspace-post).

List snippets in a workspace

Identical to [`/snippets`](/cloud/bitbucket/rest/api-group-snippets/#api-snippets-get), except that the result is further filtered by the snippet owner and only those that are owned by `{workspace}` are returned.

Create a snippet for a workspace

Identical to [`/snippets`](/cloud/bitbucket/rest/api-group-snippets/#api-snippets-post), except that the new snippet will be created under the workspace specified in the path parameter `{workspace}`.

Get a snippet

Retrieves a single snippet. Snippets support multiple content types: * application/json * multipart/related * multipart/form-data application/json ---------------- The default content type of the response is `application/json`. Since JSON is always `utf-8`, it cannot reliably contain file contents for files that are not text. Therefore, JSON snippet documents only contain the filename and links to the file contents. This means that in order to retrieve all parts of a snippet, N+1 requests need to be made (where N is the number of files in the snippet). multipart/related ----------------- To retrieve an entire snippet in a single response, use the `Accept: multipart/related` HTTP request header. $ curl -H "Accept: multipart/related" https://api.bitbucket.org/2.0/snippets/evzijst/1 Response: HTTP/1.1 200 OK Content-Length: 2214 Content-Type: multipart/related; start="snippet"; boundary="===============1438169132528273974==" MIME-Version: 1.0 --===============1438169132528273974== Content-Type: application/json; charset="utf-8" MIME-Version: 1.0 Content-ID: snippet { "links": { "self": { "href": "https://api.bitbucket.org/2.0/snippets/evzijst/kypj" }, "html": { "href": "https://bitbucket.org/snippets/evzijst/kypj" }, "comments": { "href": "https://api.bitbucket.org/2.0/snippets/evzijst/kypj/comments" }, "watchers": { "href": "https://api.bitbucket.org/2.0/snippets/evzijst/kypj/watchers" }, "commits": { "href": "https://api.bitbucket.org/2.0/snippets/evzijst/kypj/commits" } }, "id": kypj, "title": "My snippet", "created_on": "2014-12-29T22:22:04.790331+00:00", "updated_on": "2014-12-29T22:22:04.790331+00:00", "is_private": false, "files": { "foo.txt": { "links": { "self": { "href": "https://api.bitbucket.org/2.0/snippets/evzijst/kypj/files/367ab19/foo.txt" }, "html": { "href": "https://bitbucket.org/snippets/evzijst/kypj#file-foo.txt" } } }, "image.png": { "links": { "self": { "href": "https://api.bitbucket.org/2.0/snippets/evzijst/kypj/files/367ab19/image.png" }, "html": { "href": "https://bitbucket.org/snippets/evzijst/kypj#file-image.png" } } } ], "owner": { "username": "evzijst", "nickname": "evzijst", "display_name": "Erik van Zijst", "uuid": "{d301aafa-d676-4ee0-88be-962be7417567}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/evzijst" }, "html": { "href": "https://bitbucket.org/evzijst" }, "avatar": { "href": "https://bitbucket-staging-assetroot.s3.amazonaws.com/c/photos/2013/Jul/31/erik-avatar-725122544-0_avatar.png" } } }, "creator": { "username": "evzijst", "nickname": "evzijst", "display_name": "Erik van Zijst", "uuid": "{d301aafa-d676-4ee0-88be-962be7417567}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/evzijst" }, "html": { "href": "https://bitbucket.org/evzijst" }, "avatar": { "href": "https://bitbucket-staging-assetroot.s3.amazonaws.com/c/photos/2013/Jul/31/erik-avatar-725122544-0_avatar.png" } } } } --===============1438169132528273974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-ID: "foo.txt" Content-Disposition: attachment; filename="foo.txt" foo --===============1438169132528273974== Content-Type: image/png MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-ID: "image.png" Content-Disposition: attachment; filename="image.png" iVBORw0KGgoAAAANSUhEUgAAABQAAAAoCAYAAAD+MdrbAAABD0lEQVR4Ae3VMUoDQRTG8ccUaW2m TKONFxArJYJamCvkCnZTaa+VnQdJSBFl2SMsLFrEWNjZBZs0JgiL/+KrhhVmJRbCLPx4O+/DT2TB cbblJxf+UWFVVRNsEGAtgvJxnLm2H+A5RQ93uIl+3632PZyl/skjfOn9Gvdwmlcw5aPUwimG+NT5 EnNN036IaZePUuIcK533NVfal7/5yjWeot2z9ta1cAczHEf7I+3J0ws9Cgx0fsOFpmlfwKcWPuBQ 73Oc4FHzBaZ8llq4q1mr5B2mOUCt815qYR8eB1hG2VJ7j35q4RofaH7IG+Xrf/PfJhfmwtfFYoIN AqxFUD6OMxcvkO+UfKfkOyXfKdsv/AYCHMLVkHAFWgAAAABJRU5ErkJggg== --===============1438169132528273974==-- multipart/form-data ------------------- As with creating new snippets, `multipart/form-data` can be used as an alternative to `multipart/related`. However, the inherently flat structure of form-data means that only basic, root-level properties can be returned, while nested elements like `links` are omitted: $ curl -H "Accept: multipart/form-data" https://api.bitbucket.org/2.0/snippets/evzijst/kypj Response: HTTP/1.1 200 OK Content-Length: 951 Content-Type: multipart/form-data; boundary=----------------------------63a4b224c59f ------------------------------63a4b224c59f Content-Disposition: form-data; name="title" Content-Type: text/plain; charset="utf-8" My snippet ------------------------------63a4b224c59f-- Content-Disposition: attachment; name="file"; filename="foo.txt" Content-Type: text/plain foo ------------------------------63a4b224c59f Content-Disposition: attachment; name="file"; filename="image.png" Content-Transfer-Encoding: base64 Content-Type: application/octet-stream iVBORw0KGgoAAAANSUhEUgAAABQAAAAoCAYAAAD+MdrbAAABD0lEQVR4Ae3VMUoDQRTG8ccUaW2m TKONFxArJYJamCvkCnZTaa+VnQdJSBFl2SMsLFrEWNjZBZs0JgiL/+KrhhVmJRbCLPx4O+/DT2TB cbblJxf+UWFVVRNsEGAtgvJxnLm2H+A5RQ93uIl+3632PZyl/skjfOn9Gvdwmlcw5aPUwimG+NT5 EnNN036IaZePUuIcK533NVfal7/5yjWeot2z9ta1cAczHEf7I+3J0ws9Cgx0fsOFpmlfwKcWPuBQ 73Oc4FHzBaZ8llq4q1mr5B2mOUCt815qYR8eB1hG2VJ7j35q4RofaH7IG+Xrf/PfJhfmwtfFYoIN AqxFUD6OMxcvkO+UfKfkOyXfKdsv/AYCHMLVkHAFWgAAAABJRU5ErkJggg== ------------------------------5957323a6b76--

Update a snippet

Used to update a snippet. Use this to add and delete files and to change a snippet's title. To update a snippet, one can either PUT a full snapshot, or only the parts that need to be changed. The contract for PUT on this API is that properties missing from the request remain untouched so that snippets can be efficiently manipulated with differential payloads. To delete a property (e.g. the title, or a file), include its name in the request, but omit its value (use `null`). As in Git, explicit renaming of files is not supported. Instead, to rename a file, delete it and add it again under another name. This can be done atomically in a single request. Rename detection is left to the SCM. PUT supports three different content types for both request and response bodies: * `application/json` * `multipart/related` * `multipart/form-data` The content type used for the request body can be different than that used for the response. Content types are specified using standard HTTP headers. Use the `Content-Type` and `Accept` headers to select the desired request and response format. application/json ---------------- As with creation and retrieval, the content type determines what properties can be manipulated. `application/json` does not support file contents and is therefore limited to a snippet's meta data. To update the title, without changing any of its files: $ curl -X POST -H "Content-Type: application/json" https://api.bitbucket.org/2.0/snippets/evzijst/kypj -d '{"title": "Updated title"}' To delete the title: $ curl -X POST -H "Content-Type: application/json" https://api.bitbucket.org/2.0/snippets/evzijst/kypj -d '{"title": null}' Not all parts of a snippet can be manipulated. The owner and creator for instance are immutable. multipart/related ----------------- `multipart/related` can be used to manipulate all of a snippet's properties. The body is identical to a POST. properties omitted from the request are left unchanged. Since the `start` part contains JSON, the mechanism for manipulating the snippet's meta data is identical to `application/json` requests. To update one of a snippet's file contents, while also changing its title: PUT /2.0/snippets/evzijst/kypj HTTP/1.1 Content-Length: 288 Content-Type: multipart/related; start="snippet"; boundary="===============1438169132528273974==" MIME-Version: 1.0 --===============1438169132528273974== Content-Type: application/json; charset="utf-8" MIME-Version: 1.0 Content-ID: snippet { "title": "My updated snippet", "files": { "foo.txt": {} } } --===============1438169132528273974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-ID: "foo.txt" Content-Disposition: attachment; filename="foo.txt" Updated file contents. --===============1438169132528273974==-- Here only the parts that are changed are included in the body. The other files remain untouched. Note the use of the `files` list in the JSON part. This list contains the files that are being manipulated. This list should have corresponding multiparts in the request that contain the new contents of these files. If a filename in the `files` list does not have a corresponding part, it will be deleted from the snippet, as shown below: PUT /2.0/snippets/evzijst/kypj HTTP/1.1 Content-Length: 188 Content-Type: multipart/related; start="snippet"; boundary="===============1438169132528273974==" MIME-Version: 1.0 --===============1438169132528273974== Content-Type: application/json; charset="utf-8" MIME-Version: 1.0 Content-ID: snippet { "files": { "image.png": {} } } --===============1438169132528273974==-- To simulate a rename, delete a file and add the same file under another name: PUT /2.0/snippets/evzijst/kypj HTTP/1.1 Content-Length: 212 Content-Type: multipart/related; start="snippet"; boundary="===============1438169132528273974==" MIME-Version: 1.0 --===============1438169132528273974== Content-Type: application/json; charset="utf-8" MIME-Version: 1.0 Content-ID: snippet { "files": { "foo.txt": {}, "bar.txt": {} } } --===============1438169132528273974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-ID: "bar.txt" Content-Disposition: attachment; filename="bar.txt" foo --===============1438169132528273974==-- multipart/form-data ----------------- Again, one can also use `multipart/form-data` to manipulate file contents and meta data atomically. $ curl -X PUT http://localhost:12345/2.0/snippets/evzijst/kypj -F title="My updated snippet" -F file=@foo.txt PUT /2.0/snippets/evzijst/kypj HTTP/1.1 Content-Length: 351 Content-Type: multipart/form-data; boundary=----------------------------63a4b224c59f ------------------------------63a4b224c59f Content-Disposition: form-data; name="file"; filename="foo.txt" Content-Type: text/plain foo ------------------------------63a4b224c59f Content-Disposition: form-data; name="title" My updated snippet ------------------------------63a4b224c59f To delete a file, omit its contents while including its name in the `files` field: $ curl -X PUT https://api.bitbucket.org/2.0/snippets/evzijst/kypj -F files=image.png PUT /2.0/snippets/evzijst/kypj HTTP/1.1 Content-Length: 149 Content-Type: multipart/form-data; boundary=----------------------------ef8871065a86 ------------------------------ef8871065a86 Content-Disposition: form-data; name="files" image.png ------------------------------ef8871065a86-- The explicit use of the `files` element in `multipart/related` and `multipart/form-data` is only required when deleting files. The default mode of operation is for file parts to be processed, regardless of whether or not they are listed in `files`, as a convenience to the client.

Delete a snippet

Deletes a snippet and returns an empty response.

List comments on a snippet

Used to retrieve a paginated list of all comments for a specific snippet. This resource works identical to commit and pull request comments. The default sorting is oldest to newest and can be overridden with the `sort` query parameter.

Create a comment on a snippet

Creates a new comment. The only required field in the body is `content.raw`. To create a threaded reply to an existing comment, include `parent.id`.

Get a comment on a snippet

Returns the specific snippet comment.

Update a comment on a snippet

Updates a comment. The only required field in the body is `content.raw`. Comments can only be updated by their author.

Delete a comment on a snippet

Deletes a snippet comment. Comments can only be removed by the comment author, snippet creator, or workspace admin.

List snippet changes

Returns the changes (commits) made on this snippet.

Get a previous snippet change

Returns the changes made on this snippet in this commit.

Get a snippet's raw file at HEAD

Convenience resource for getting to a snippet's raw files without the need for first having to retrieve the snippet itself and having to pull out the versioned file links.

Check if the current user is watching a snippet

Used to check if the current user is watching a specific snippet. Returns 204 (No Content) if the user is watching the snippet and 404 if not. Hitting this endpoint anonymously always returns a 404.

Watch a snippet

Used to start watching a specific snippet. Returns 204 (No Content).

Stop watching a snippet

Used to stop watching a specific snippet. Returns 204 (No Content) to indicate success.

List users watching a snippet

Returns a paginated list of all users watching a specific snippet.

Get a previous revision of a snippet

Identical to `GET /snippets/encoded_id`, except that this endpoint can be used to retrieve the contents of the snippet as it was at an older revision, while `/snippets/encoded_id` always returns the snippet's current revision. Note that only the snippet's file contents are versioned, not its meta data properties like the title. Other than that, the two endpoints are identical in behavior.

Update a previous revision of a snippet

Identical to `UPDATE /snippets/encoded_id`, except that this endpoint takes an explicit commit revision. Only the snippet's "HEAD"/"tip" (most recent) version can be updated and requests on all other, older revisions fail by returning a 405 status. Usage of this endpoint over the unrestricted `/snippets/encoded_id` could be desired if the caller wants to be sure no concurrent modifications have taken place between the moment of the UPDATE request and the original GET. This can be considered a so-called "Compare And Swap", or CAS operation. Other than that, the two endpoints are identical in behavior.

Delete a previous revision of a snippet

Deletes the snippet. Note that this only works for versioned URLs that point to the latest commit of the snippet. Pointing to an older commit results in a 405 status code. To delete a snippet, regardless of whether or not concurrent changes are being made to it, use `DELETE /snippets/{encoded_id}` instead.

Get a snippet's raw file

Retrieves the raw contents of a specific file in the snippet. The `Content-Disposition` header will be "attachment" to avoid issues with malevolent executable files. The file's mime type is derived from its filename and returned in the `Content-Type` header. Note that for text files, no character encoding is included as part of the content type.

Get snippet changes between versions

Returns the diff of the specified commit against its first parent. Note that this resource is different in functionality from the `patch` resource. The differences between a diff and a patch are: * patches have a commit header with the username, message, etc * diffs support the optional `path=foo/bar.py` query param to filter the diff to just that one file diff (not supported for patches) * for a merge, the diff will show the diff between the merge commit and its first parent (identical to how PRs work), while patch returns a response containing separate patches for each commit on the second parent's ancestry, up to the oldest common ancestor (identical to its reachability). Note that the character encoding of the contents of the diff is unspecified as Git does not track this, making it hard for Bitbucket to reliably determine this.

Get snippet patch between versions

Returns the patch of the specified commit against its first parent. Note that this resource is different in functionality from the `diff` resource. The differences between a diff and a patch are: * patches have a commit header with the username, message, etc * diffs support the optional `path=foo/bar.py` query param to filter the diff to just that one file diff (not supported for patches) * for a merge, the diff will show the diff between the merge commit and its first parent (identical to how PRs work), while patch returns a response containing separate patches for each commit on the second parent's ancestry, up to the oldest common ancestor (identical to its reachability). Note that the character encoding of the contents of the patch is unspecified as Git does not track this, making it hard for Bitbucket to reliably determine this.

List variables for an account

Find account level variables. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).

Create a variable for a user

Create an account level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).

Get a variable for a team

Retrieve a team level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).

Update a variable for a team

Update a team level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).

Delete a variable for a team

Delete a team level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).

Search for code in a team's repositories

Search for code in the repositories of the specified team. Searching across all repositories: Note that searches can match in the file's text (`content_matches`), the path (`path_matches`), or both as in the example above. You can use the same syntax for the search query as in the UI, e.g. to only search within a specific repository: Similar to other APIs, you can request more fields using a `fields` query parameter. E.g. to get some more information about the repository of matched files (the `%2B` is a URL-encoded `+`): Try `fields=%2Bvalues.*.*.*.*` to get an idea what's possible.

Get current user

Returns the currently logged in user.

List email addresses for current user

Returns all the authenticated user's email addresses. Both confirmed and unconfirmed.

Get an email address for current user

Returns details about a specific one of the authenticated user's email addresses. Details describe whether the address has been confirmed by the user and whether it is the user's primary address or not.

List repository permissions for a user

Returns an object for each repository the caller has explicit access to and their effective permission — the highest level of permission the caller has. This does not return public repositories that the user was not granted any specific permission in, and does not distinguish between explicit and implicit privileges. Permissions can be: * `admin` * `write` * `read` Results may be further [filtered or sorted](/cloud/bitbucket/rest/intro/#filtering) by repository or permission by adding the following query string parameters: * `q=repository.name="geordi"` or `q=permission>"read"` * `sort=repository.name` Note that the query parameter values need to be URL escaped so that `=` would become `%3D`.

List workspaces for the current user

Returns an object for each workspace the caller is a member of, and their effective role - the highest level of privilege the caller has. If a user is a member of multiple groups with distinct roles, only the highest level is returned. Permissions can be: * `owner` * `collaborator` * `member` **The `collaborator` role is being removed from the Bitbucket Cloud API. For more information, see the [deprecation announcement](/cloud/bitbucket/deprecation-notice-collaborator-role/).** **When you move your administration from Bitbucket Cloud to admin.atlassian.com, the following fields on `workspace_membership` will no longer be present: `last_accessed` and `added_on`. See the [deprecation announcement](/cloud/bitbucket/announcement-breaking-change-workspace-membership/).** Results may be further [filtered or sorted](/cloud/bitbucket/rest/intro/#filtering) by workspace or permission by adding the following query string parameters: * `q=workspace.slug="bbworkspace1"` or `q=permission="owner"` * `sort=workspace.slug` Note that the query parameter values need to be URL escaped so that `=` would become `%3D`.

Get a user

Gets the public information associated with a user account. If the user's profile is private, `location`, `website` and `created_on` elements are omitted. Note that the user object returned by this operation is changing significantly, due to privacy changes. See the [announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-changes-gdpr/#changes-to-bitbucket-user-objects) for details.

List variables for a user

Find user level variables. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).

Create a variable for a user

Create a user level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).

Get a variable for a user

Retrieve a user level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).

Update a variable for a user

Update a user level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).

Delete a variable for a user

Delete an account level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).

Get a user application property

Retrieve an [application property](/cloud/bitbucket/application-properties/) value stored against a user.

Update a user application property

Update an [application property](/cloud/bitbucket/application-properties/) value stored against a user.

Delete a user application property

Delete an [application property](/cloud/bitbucket/application-properties/) value stored against a user.

Search for code in a user's repositories

Search for code in the repositories of the specified user. Searching across all repositories: Note that searches can match in the file's text (`content_matches`), the path (`path_matches`), or both as in the example above. You can use the same syntax for the search query as in the UI, e.g. to only search within a specific repository: Similar to other APIs, you can request more fields using a `fields` query parameter. E.g. to get some more information about the repository of matched files (the `%2B` is a URL-encoded `+`): Try `fields=%2Bvalues.*.*.*.*` to get an idea what's possible.

List workspaces for user

Returns a list of workspaces accessible by the authenticated user. Results may be further [filtered or sorted](/cloud/bitbucket/rest/intro/#filtering) by workspace or permission by adding the following query string parameters: * `q=slug="bbworkspace1"` or `q=is_private=true` * `sort=created_on` Note that the query parameter values need to be URL escaped so that `=` would become `%3D`. **The `collaborator` role is being removed from the Bitbucket Cloud API. For more information, see the [deprecation announcement](/cloud/bitbucket/deprecation-notice-collaborator-role/).**

Get a workspace

Returns the requested workspace.

List webhooks for a workspace

Returns a paginated list of webhooks installed on this workspace.

Create a webhook for a workspace

Creates a new webhook on the specified workspace. Workspace webhooks are fired for events from all repositories contained by that workspace. This call requires the webhook scope, as well as any scope that applies to the events that the webhook subscribes to. In the example above that means: `webhook`, `repository` and `issue`. The `url` must properly resolve and cannot be an internal, non-routed address. Only workspace owners can install webhooks on workspaces.

Get a webhook for a workspace

Returns the webhook with the specified id installed on the given workspace.

Update a webhook for a workspace

Updates the specified webhook subscription. The following properties can be mutated: * `description` * `url` * `active` * `events`

Delete a webhook for a workspace

Deletes the specified webhook subscription from the given workspace.

List users in a workspace

Returns all members of the requested workspace.

Get user membership for a workspace

Returns the workspace membership, which includes a `User` object for the member and a `Workspace` object for the requested workspace.

List user permissions in a workspace

Returns the list of members in a workspace and their permission levels. Permission can be: * `owner` * `collaborator` * `member` **The `collaborator` role is being removed from the Bitbucket Cloud API. For more information, see the [deprecation announcement](/cloud/bitbucket/deprecation-notice-collaborator-role/).** **When you move your administration from Bitbucket Cloud to admin.atlassian.com, the following fields on `workspace_membership` will no longer be present: `last_accessed` and `added_on`. See the [deprecation announcement](/cloud/bitbucket/announcement-breaking-change-workspace-membership/).** Results may be further [filtered](/cloud/bitbucket/rest/intro/#filtering) by permission by adding the following query string parameters: * `q=permission="owner"`

List all repository permissions for a workspace

Returns an object for each repository permission for all of a workspace's repositories. Permissions returned are effective permissions: the highest level of permission the user has. This does not distinguish between direct and indirect (group) privileges. Only users with admin permission for the team may access this resource. Permissions can be: * `admin` * `write` * `read` Results may be further [filtered or sorted](/cloud/bitbucket/rest/intro/#filtering) by repository, user, or permission by adding the following query string parameters: * `q=repository.name="geordi"` or `q=permission>"read"` * `sort=user.display_name` Note that the query parameter values need to be URL escaped so that `=` would become `%3D`.

List a repository permissions for a workspace

Returns an object for the repository permission of each user in the requested repository. Permissions returned are effective permissions: the highest level of permission the user has. This does not distinguish between direct and indirect (group) privileges. Only users with admin permission for the repository may access this resource. Permissions can be: * `admin` * `write` * `read` Results may be further [filtered or sorted](/cloud/bitbucket/rest/intro/#filtering) by user, or permission by adding the following query string parameters: * `q=permission>"read"` * `sort=user.display_name` Note that the query parameter values need to be URL escaped so that `=` would become `%3D`.

List variables for a workspace

Find workspace level variables.

Create a variable for a workspace

Create a workspace level variable.

Get variable for a workspace

Retrieve a workspace level variable.

Update variable for a workspace

Update a workspace level variable.

Delete a variable for a workspace

Delete a workspace level variable.

List projects in a workspace

Returns the list of projects in this workspace.

Create a project in a workspace

Creates a new project. Note that the avatar has to be embedded as either a data-url or a URL to an external image as shown in the examples below: or even:

Get a project for a workspace

Returns the requested project.

Update a project for a workspace

Since this endpoint can be used to both update and to create a project, the request body depends on the intent. #### Creation See the POST documentation for the project collection for an example of the request body. Note: The `key` should not be specified in the body of request (since it is already present in the URL). The `name` is required, everything else is optional. #### Update See the POST documentation for the project collection for an example of the request body. Note: The key is not required in the body (since it is already in the URL). The key may be specified in the body, if the intent is to change the key itself. In such a scenario, the location of the project is changed and is returned in the `Location` header of the response.

Delete a project for a workspace

Deletes this project. This is an irreversible operation. You cannot delete a project that still contains repositories. To delete the project, [delete](/cloud/bitbucket/rest/api-group-repositories/#api-repositories-workspace-repo-slug-delete) or transfer the repositories first.

Get the branching model for a project

Return the branching model set at the project level. This view is read-only. The branching model settings can be changed using the [settings](#api-workspaces-workspace-projects-project-key-branching-model-settings-get) API. The returned object: 1. Always has a `development` property. `development.name` is the user-specified branch that can be inherited by an individual repository's branching model. 2. Might have a `production` property. `production` will not be present when `production` is disabled. `production.name` is the user-specified branch that can be inherited by an individual repository's branching model. 3. Always has a `branch_types` array which contains all enabled branch types.

Get the branching model config for a project

Return the branching model configuration for a project. The returned object: 1. Always has a `development` property for the development branch. 2. Always a `production` property for the production branch. The production branch can be disabled. 3. The `branch_types` contains all the branch types. This is the raw configuration for the branching model. A client wishing to see the branching model with its actual current branches may find the [active model API](#api-workspaces-workspace-projects-project-key-branching-model-get) more useful.

Update the branching model config for a project

Update the branching model configuration for a project. The `development` branch can be configured to a specific branch or to track the main branch. Any branch name can be supplied, but will only successfully be applied to a repository via inheritance if that branch exists for that repository. Only the passed properties will be updated. The properties not passed will be left unchanged. A request without a `development` property will leave the development branch unchanged. The `production` branch can be a specific branch, the main branch or disabled. Any branch name can be supplied, but will only successfully be applied to a repository via inheritance if that branch exists for that repository. The `enabled` property can be used to enable (`true`) or disable (`false`) it. Only the passed properties will be updated. The properties not passed will be left unchanged. A request without a `production` property will leave the production branch unchanged. The `branch_types` property contains the branch types to be updated. Only the branch types passed will be updated. All updates will be rejected if it would leave the branching model in an invalid state. For branch types this means that: 1. The prefixes for all enabled branch types are valid. For example, it is not possible to use '*' inside a Git prefix. 2. A prefix of an enabled branch type must not be a prefix of another enabled branch type. This is to ensure that a branch can be easily classified by its prefix unambiguously. It is possible to store an invalid prefix if that branch type would be left disabled. Only the passed properties will be updated. The properties not passed will be left unchanged. Each branch type must have a `kind` property to identify it.

List the default reviewers in a project

Return a list of all default reviewers for a project. This is a list of users that will be added as default reviewers to pull requests for any repository within the project.

Get a default reviewer

Returns the specified default reviewer.

Add the specific user as a default reviewer for the project

Adds the specified user to the project's list of default reviewers. The method is idempotent. Accepts an optional body containing the `uuid` of the user to be added.

Remove the specific user from the project's default reviewers

Removes a default reviewer from the project.

List explicit group permissions for a project

Returns a paginated list of explicit group permissions for the given project. This endpoint does not support BBQL features.

Get an explicit group permission for a project

Returns the group permission for a given group and project. Only users with admin permission for the project may access this resource. Permissions can be: * `admin` * `create-repo` * `write` * `read` * `none`

Update an explicit group permission for a project

Updates the group permission if it exists. Only users with admin permission for the project may access this resource. Due to security concerns, the JWT and OAuth authentication methods are unsupported. This is to ensure integrations and add-ons are not allowed to change permissions. Permissions can be: * `admin` * `create-repo` * `write` * `read`

Delete an explicit group permission for a project

Deletes the project group permission between the requested project and group, if one exists. Only users with admin permission for the project may access this resource.

List explicit user permissions for a project

Returns a paginated list of explicit user permissions for the given project. This endpoint does not support BBQL features.

Get an explicit user permission for a project

Returns the explicit user permission for a given user and project. Only users with admin permission for the project may access this resource. Permissions can be: * `admin` * `create-repo` * `write` * `read` * `none`

Update an explicit user permission for a project

Updates the explicit user permission for a given user and project. The selected user must be a member of the workspace, and cannot be the workspace owner. Only users with admin permission for the project may access this resource. Due to security concerns, the JWT and OAuth authentication methods are unsupported. This is to ensure integrations and add-ons are not allowed to change permissions. Permissions can be: * `admin` * `create-repo` * `write` * `read`

Delete an explicit user permission for a project

Deletes the project user permission between the requested project and user, if one exists. Only users with admin permission for the project may access this resource. Due to security concerns, the JWT and OAuth authentication methods are unsupported. This is to ensure integrations and add-ons are not allowed to change permissions.

Search for code in a workspace

Search for code in the repositories of the specified workspace. Searching across all repositories: Note that searches can match in the file's text (`content_matches`), the path (`path_matches`), or both as in the example above. You can use the same syntax for the search query as in the UI, e.g. to only search within a specific repository: Similar to other APIs, you can request more fields using a `fields` query parameter. E.g. to get some more information about the repository of matched files (the `%2B` is a URL-encoded `+`): Try `fields=%2Bvalues.*.*.*.*` to get an idea what's possible.

and 264 more

Generic HTTP Request

Every SaaS integration in Superblocks comes with a built in Generic HTTP Request Action. This is a powerful action you can use to call Bitbucket API endpoints not in the Superblocks supported actions.

To use this action simply add the method, path, required query parameters, and body for the desired endpoint.

info

Learn more about REST requests in Superblocks in our Building REST requests guide.

Generic HTTP Requests use the authentication set up and base URL you've configured for your integration, making it an easy for your team to extend Superblocks Integrations to meet their needs.