Bitbucket

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: ``` curl --location 'https://api.bitbucket.org/2.0/repositories/<username>/<reposity-name>/commit/<commit-hash>/reports/mysystem-001/annotations' \ --header 'Content-Type: application/json' \ --data-raw '[ { "external_id": "mysystem-annotation001", "title": "Security scan report", "annotation_type": "VULNERABILITY", "summary": "This line represents a security threat.", "severity": "HIGH", "path": "my-service/src/main/java/com/myCompany/mysystem/logic/Main.java", "line": 42 }, { "external_id": "mySystem-annotation002", "title": "Bug report", "annotation_type": "BUG", "result": "FAILED", "summary": "This line might introduce a bug.", "severity": "MEDIUM", "path": "my-service/src/main/java/com/myCompany/mysystem/logic/Helper.java", "line": 13 } ]' ``` ### 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.

Create a deployment environment level variable.

Create an environment.

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: ``` curl --request PUT 'https://api.bitbucket.org/2.0/repositories/<username>/<reposity-name>/commit/<commit-hash>/reports/mySystem-001/annotations/mysystem-annotation001' \ --header 'Content-Type: application/json' \ --data-raw '{ "title": "Security scan report", "annotation_type": "VULNERABILITY", "summary": "This line represents a security thread.", "severity": "HIGH", "path": "my-service/src/main/java/com/myCompany/mysystem/logic/Main.java", "line": 42 }' ``` ### 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.

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: ``` curl --request PUT 'https://api.bitbucket.org/2.0/repositories/<username>/<reposity-name>/commit/<commit-hash>/reports/mysystem-001' \ --header 'Content-Type: application/json' \ --data-raw '{ "title": "Security scan report", "details": "This pull request introduces 10 new dependency vulnerabilities.", "report_type": "SECURITY", "reporter": "mySystem", "link": "http://www.mysystem.com/reports/001", "result": "FAILED", "data": [ { "title": "Duration (seconds)", "type": "DURATION", "value": 14 }, { "title": "Safe to merge?", "type": "BOOLEAN", "value": false } ] }' ``` ### 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.

Endpoint to create and initiate a pipeline. There are a number 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. ### Example ``` $ curl -X POST -is -u '{atlassian_account_email}:{api_token}' \ -H 'Content-Type: application/json' \ https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines/ \ -d ' { "target": { "ref_type": "branch", "type": "pipeline_ref_target", "ref_name": "master" } }' ``` ## 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` ### Example ``` $ curl -X POST -is -u '{atlassian_account_email}:{api_token}' \ -H 'Content-Type: application/json' \ https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines/ \ -d ' { "target": { "commit": { "type": "commit", "hash": "ce5b7431602f7cbba007062eeb55225c6e18e956" }, "ref_type": "branch", "type": "pipeline_ref_target", "ref_name": "master" } }' ``` ## 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. ### Example ``` $ curl -X POST -is -u '{atlassian_account_email}:{api_token}' \ -H 'Content-Type: application/json' \ https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines/ \ -d ' { "target": { "commit": { "hash":"a3c4e02c9a3755eccdc3764e6ea13facdf30f923", "type":"commit" }, "selector": { "type":"custom", "pattern":"Deploy to production" }, "type":"pipeline_commit_target" } }' ``` ## 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. ### Example ``` $ curl -X POST -is -u '{atlassian_account_email}:{api_token}' \ -H 'Content-Type: application/json' \ https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines/ \ -d ' { "target": { "commit": { "hash":"a3c4e02c9a3755eccdc3764e6ea13facdf30f923", "type":"commit" }, "selector": { "type": "custom", "pattern": "Deploy to production" }, "type": "pipeline_ref_target", "ref_name": "master", "ref_type": "branch" } }' ``` ## 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). ### Example ``` $ curl -X POST -is -u '{atlassian_account_email}:{api_token}' \ -H 'Content-Type: application/json' \ https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines/ \ -d ' { "target": { "type": "pipeline_ref_target", "ref_type": "branch", "ref_name": "master", "selector": { "type": "custom", "pattern": "Deploy to production" } }, "variables": [ { "key": "var1key", "value": "var1value", "secured": true }, { "key": "var2key", "value": "var2value" } ] }' ``` ## Trigger a pull request pipeline You can also initiate a pipeline for a specific pull request. ### Example ``` $ curl -X POST -is -u '{atlassian_account_email}:{api_token}' \ -H 'Content-Type: application/json' \ https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines/ \ -d ' { "target": { "type": "pipeline_pullrequest_target", "source": "pull-request-branch", "destination": "master", "destination_commit": { "hash": "9f848b7" }, "commit": { "hash": "1a372fc" }, "pullrequest": { "id": "3" }, "selector": { "type": "pull-requests", "pattern": "**" } } }' ``` # On-demand pipeline By default, pipelines run using the YAML in the repository’s `bitbucket-pipelines.yml` configuration file. With an _on-demand_ pipeline, you include the pipeline’s YAML in the request body. That YAML applies only to that run and overrides the YAML in `bitbucket-pipelines.yml`. Just like with regular pipelines, there is a number of different options to initiate an on-demand pipeline. However, since the payload contains YAML configuration in this case, _query parameters_ are used to supply the necessary metadata to determine which type of pipeline will be instantiated. These query parameters are derived from the JSON equivalent by turning each property into a key-value pair with the JSON path of the property as the new key. ## Trigger on-demand pipeline for a branch You can initiate an on-demand pipeline for a specific branch. This branch will be used to determine which pipeline definition from the supplied YAML configuration will be applied to initiate the pipeline. The pipeline will then do a clone of the repository and check out the latest revision of the specified branch. To trigger an on-demand pipeline for a _branch_ the requesting user must have **write permission** for that branch (which can be limited by [branch restrictions](https://support.atlassian.com/bitbucket-cloud/docs/use-branch-permissions/)). ### Example ``` $ curl -X POST -is -u '{atlassian_account_email}:{api_token}' \ -H 'Content-Type: application/yaml' \ https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines?target.type=pipeline_ref_target&target.ref_type=branch&target.ref_name=master \ -d ' pipelines: default: - step: script: - echo This is an on-demand pipeline' ``` ## Trigger on-demand pipeline for a commit on a branch or tag You can initiate an on-demand pipeline for a specific commit and in the context of a specified reference (branch or tag). The specified reference will be used to determine which pipeline definition from the supplied YAML configuration will be applied to initiate the pipeline. The pipeline will clone the repository and check out the specified reference. To trigger an on-demand pipeline for a _branch_ the requesting user must have **write permission** for that branch (which can be limited by [branch restrictions](https://support.atlassian.com/bitbucket-cloud/docs/use-branch-permissions/)). ### Example ``` $ curl -X POST -is -u '{atlassian_account_email}:{api_token}' \ -H 'Content-Type: application/yaml' \ https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines?target.type=pipeline_ref_target&target.ref_type=branch&target.ref_name=master&target.commit.hash=ce5b7431602f7cbba007062eeb55225c6e18e956 \ -d ' pipelines: default: - step: script: - echo This is an on-demand pipeline' ``` ## Trigger a specific on-demand pipeline definition for a commit You can trigger a specific pipeline that is defined in the supplied YAML configuration 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. ### Example ``` $ curl -X POST -is -u '{atlassian_account_email}:{api_token}' \ -H 'Content-Type: application/yaml' \ https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines?target.type=pipeline_commit_target&target.commit.hash=a3c4e02c9a3755eccdc3764e6ea13facdf30f923&target.selector.type=custom&target.selector.pattern=security-scan \ -d ' pipelines: custom: security-scan: - step: script: - echo Run on-demand security scan ``` ## Trigger a custom on-demand pipeline with variables In addition to triggering a custom on-demand pipeline that is defined in the supplied YAML configuration as shown in the examples above, you can specify variables that will be available for your build. In the request, provide each variable as an indexed set of query parameters representing its key, value, and whether it should be secured or not (this field is optional and defaults to not secured). ### Example ``` $ curl -X POST -is -u '{atlassian_account_email}:{api_token}' \ -H 'Content-Type: application/yaml' \ https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines?target.type=pipeline_ref_target&target.ref_type=branch&target.ref_name=master&target.selector.type=custom&target.selector.pattern=security-scan&variables[0].key=var1key&variables[0].value=var1value&variables[0].secured=true&variables[1].key=var2key&variables[1].value=var2value \ -d ' pipelines: custom: security-scan: - variables: - name: var1key - name: var2key - step: script: - echo Run on-demand security scan' ``` ## Trigger a pull request pipeline You can also initiate an on-demand pipeline for a specific pull request. ### Example ``` $ curl -X POST -is -u '{atlassian_account_email}:{api_token}' \ -H 'Content-Type: application/yaml' \ https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines?target.type=pipeline_pullrequest_target&target.source=pull-request-branch&target.destination=destination&target.destination_commit.hash=9f848b7&target.commit.hash=1a372fc&target.pullrequest.id=3&target.selector.type=pull-requests&target.selector.pattern=** \ -d ' pipelines: pull-requests: "**": - step: script: - echo This is an on-demand pipeline' ```

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/).

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/).

Create a workspace level variable.

Create a repository level known host.

Create a schedule for the given repository.

Create a repository level variable.

Create repository runner.

Create workspace runner.

Deletes the application for the user. This endpoint is intended to be used by Bitbucket Connect apps and only supports JWT authentication -- that is how Bitbucket identifies the particular installation of the app. Developers with applications registered in the "Develop Apps" section of Bitbucket Marketplace need not use this endpoint as updates for those applications can be sent out via the UI of that section. ``` $ curl -X DELETE https://api.bitbucket.org/2.0/addon \ -H "Authorization: JWT <JWT Token>" ```

Deletes a single Annotation matching the provided ID.

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

Delete a deployment environment level variable.

Delete an environment

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/).

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/).

Delete a workspace level variable.

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

Deletes a single Report matching the provided ID.

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

Deletes an existing branch restriction rule.

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.

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.

Removes a default reviewer from the repository.

This deletes a deploy key from a repository.

Deletes the specified download artifact from the repository.

Deletes the specified webhook subscription from the given repository.

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

Deletes an attachment.

Deletes the specified comment.

Retract your vote.

Stop watching this issue.

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. The only authentication method supported for this endpoint is via app passwords.

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.

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

Deletes a specific pull request comment.

Reopen a comment thread

Remove change request for a pull request

Deletes a specific pull request task.

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).

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

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

Delete a repository cache.

Delete repository cache versions by name.

Delete the repository SSH key pair.

Delete a repository level known host.

Delete a schedule.

Delete a repository level variable.

Delete repository runner by uuid.

Deletes a snippet and returns an empty response.

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

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.

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

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

Deletes a specific GPG public key from a user's account.

Deletes a specific SSH public key from a user's account.

Delete workspace runner by uuid.

Deletes the specified webhook subscription from the given 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. Example: ``` $ curl -X DELETE https://api.bitbucket.org/2.0/workspaces/bbworkspace1/projects/PROJ ```

Removes a default reviewer from the project. Example: ``` $ curl https://api.bitbucket.org/2.0/.../default-reviewers/%7Bf0e0e8e9-66c1-4b85-a784-44a9eb9ef1a6%7D HTTP/1.1 204 ```

This deletes a deploy key from 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.

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.

Get the client key of the Connect addon associated with a Forge app install via forgeAppId linkage. This endpoint is part of the Connect -> Forge migration tooling. It is intended to be used by a Forge app using `asApp().requestBitbucket()` only. Prerequisite: app developer needs to register the linkage between their Connect and Forge app by setting `forgeAppId` in the Connect addon descriptor to `app.id` from Forge app manifest, then update the installations. If the request came from an installation of a registered Forge app, the client key of the linked Connect addon installed in the same workspace will be returned. ``` api.asApp().requestBitbucket(route`/2.0/addon/{addon-key}/client-key`) ```

Returns a single Annotation matching the provided ID.

Returns a paginated list of Annotations for a specified report.

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

Retrieve a deployment

Find deployment environment level variables.

Find deployments

Retrieve an environment

Find environments

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.

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.

This is part of OpenID Connect for Pipelines, see https://support.atlassian.com/bitbucket-cloud/docs/integrate-pipelines-with-resource-servers-using-oidc/

This is part of OpenID Connect for Pipelines, see https://support.atlassian.com/bitbucket-cloud/docs/integrate-pipelines-with-resource-servers-using-oidc/

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.

Retrieve a specified pipeline

Retrieve a given step of a pipeline.

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.

Find steps for the given pipeline.

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

Get test cases for a given step of a pipeline.

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

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/).

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/).

Retrieve a workspace level variable.

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/).

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/).

Find workspace level variables.

Find pipelines in a repository. Note that unlike other endpoints in the Bitbucket API, this endpoint utilizes query parameters to allow filtering and sorting of returned results. See [query parameters](#api-repositories-workspace-repo-slug-pipelines-get-request-Query%20parameters) for specific details.

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

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.

Returns a single Report matching the provided ID.

Returns a paginated list of Reports linked to this commit.

**This endpoint is deprecated. Please use the [workspace scoped alternative](/cloud/bitbucket/rest/api-group-repositories/#api-repositories-workspace-get).** 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.

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.

Returns the object describing this repository.

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

Returns a specific branch restriction rule.

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.

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. 4. `default_branch_deletion` indicates whether branches will be deleted by default on merge. 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.

Returns the specified commit.

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.

Returns the specified commit comment.

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

Returns the specified build status for a commit.

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.

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.

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

Returns the specified issue tracker component object.

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.

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.

Returns all deploy-keys belonging to a repository.

Returns the deploy key belonging to a specific key.

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`.

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`.

Returns a list of download links associated with the repository.

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

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

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.

Get file conflicts for a commit spec

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. The example response returns commits made before 2011-05-18 against a file named `README.rst`. The results are filtered to only return the path and date. This request can be made using: ``` $ curl 'https://api.bitbucket.org/2.0/repositories/evzijst/dogslow/filehistory/master/README.rst'\ '?fields=values.next,values.path,values.commit.date&q=commit.date<=2011-05-18' ``` 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`.

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

Returns a paginated list of webhooks installed on this repository.

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

Returns the issues in the issue tracker.

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 202 response with in the response body a description of the current status. After the job has been scheduled, but before it starts executing, the endpoint returns a 202 response with status `ACCEPTED`. 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`.

When using GET, this endpoint reports the status of the current import task. After the job has been scheduled, but before it starts executing, the endpoint returns a 202 response with status `ACCEPTED`. 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`.

Returns the specified 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.

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.

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": ``` $ curl -s https://api.bitbucket.org/2.0/repositories/site/master/issues/1/changes \ -G --data-urlencode='q=changes.state.new = "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.

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

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.

Returns the specified issue comment object.

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.

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

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.

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

Returns the specified issue tracker milestone object.

Retrieve the inheritance state for repository settings

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`.

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

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`

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

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`

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.

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: ``` { "pagelen": 20, "values": [ { "comment": { "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/pullrequests/5695/comments/118571088" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/pull-requests/5695/_/diff#comment-118571088" } }, "deleted": false, "pullrequest": { "type": "pullrequest", "id": 5695, "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/pullrequests/5695" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/pull-requests/5695" } }, "title": "username/NONE: small change from onFocus to onClick to handle tabbing through the page and not expand the editor unless a click event triggers it" }, "content": { "raw": "inline with to a dn from lines", "markup": "markdown", "html": "<p>inline with to a dn from lines</p>", "type": "rendered" }, "created_on": "2019-09-27T00:33:46.039178+00:00", "user": { "display_name": "Name Lastname", "uuid": "{}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/%7B%7D" }, "html": { "href": "https://bitbucket.org/%7B%7D/" }, "avatar": { "href": "https://avatar-management--avatars.us-west-2.prod.public.atl-paas.net/:/128" } }, "type": "user", "nickname": "Name", "account_id": "" }, "created_on": "2019-09-27T00:33:46.039178+00:00", "user": { "display_name": "Name Lastname", "uuid": "{}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/%7B%7D" }, "html": { "href": "https://bitbucket.org/%7B%7D/" }, "avatar": { "href": "https://avatar-management--avatars.us-west-2.prod.public.atl-paas.net/:/128" } }, "type": "user", "nickname": "Name", "account_id": "" }, "updated_on": "2019-09-27T00:33:46.055384+00:00", "inline": { "context_lines": "", "to": null, "path": "", "outdated": false, "from": 211 }, "type": "pullrequest_comment", "id": 118571088 }, "pull_request": { "type": "pullrequest", "id": 5695, "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/pullrequests/5695" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/pull-requests/5695" } }, "title": "username/NONE: small change from onFocus to onClick to handle tabbing through the page and not expand the editor unless a click event triggers it" } } ] } ``` Updates include a state property of OPEN, MERGED, or DECLINED. Update example: ``` { "pagelen": 20, "values": [ { "update": { "description": "", "title": "username/NONE: small change from onFocus to onClick to handle tabbing through the page and not expand the editor unless a click event triggers it", "destination": { "commit": { "type": "commit", "hash": "6a2c16e4a152", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/commit/6a2c16e4a152" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/commits/6a2c16e4a152" } } }, "branch": { "name": "master" }, "repository": { "name": "Atlaskit-MK-2", "type": "repository", "full_name": "atlassian/atlaskit-mk-2", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2" }, "avatar": { "href": "https://bytebucket.org/ravatar/%7B%7D?ts=js" } }, "uuid": "{}" } }, "reason": "", "source": { "commit": { "type": "commit", "hash": "728c8bad1813", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/commit/728c8bad1813" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/commits/728c8bad1813" } } }, "branch": { "name": "username/NONE-add-onClick-prop-for-accessibility" }, "repository": { "name": "Atlaskit-MK-2", "type": "repository", "full_name": "atlassian/atlaskit-mk-2", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2" }, "avatar": { "href": "https://bytebucket.org/ravatar/%7B%7D?ts=js" } }, "uuid": "{}" } }, "state": "OPEN", "author": { "display_name": "Name Lastname", "uuid": "{}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/%7B%7D" }, "html": { "href": "https://bitbucket.org/%7B%7D/" }, "avatar": { "href": "https://avatar-management--avatars.us-west-2.prod.public.atl-paas.net/:/128" } }, "type": "user", "nickname": "Name", "account_id": "" }, "date": "2019-05-10T06:48:25.305565+00:00" }, "pull_request": { "type": "pullrequest", "id": 5695, "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/pullrequests/5695" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/pull-requests/5695" } }, "title": "username/NONE: small change from onFocus to onClick to handle tabbing through the page and not expand the editor unless a click event triggers it" } } ] } ``` Approval example: ``` { "pagelen": 20, "values": [ { "approval": { "date": "2019-09-27T00:37:19.849534+00:00", "pullrequest": { "type": "pullrequest", "id": 5695, "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/pullrequests/5695" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/pull-requests/5695" } }, "title": "username/NONE: small change from onFocus to onClick to handle tabbing through the page and not expand the editor unless a click event triggers it" }, "user": { "display_name": "Name Lastname", "uuid": "{}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/%7B%7D" }, "html": { "href": "https://bitbucket.org/%7B%7D/" }, "avatar": { "href": "https://avatar-management--avatars.us-west-2.prod.public.atl-paas.net/:/128" } }, "type": "user", "nickname": "Name", "account_id": "" } }, "pull_request": { "type": "pullrequest", "id": 5695, "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/pullrequests/5695" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/pull-requests/5695" } }, "title": "username/NONE: small change from onFocus to onClick to handle tabbing through the page and not expand the editor unless a click event triggers it" } } ] } ```

Returns the specified pull request.

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: ``` { "pagelen": 20, "values": [ { "comment": { "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/pullrequests/5695/comments/118571088" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/pull-requests/5695/_/diff#comment-118571088" } }, "deleted": false, "pullrequest": { "type": "pullrequest", "id": 5695, "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/pullrequests/5695" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/pull-requests/5695" } }, "title": "username/NONE: small change from onFocus to onClick to handle tabbing through the page and not expand the editor unless a click event triggers it" }, "content": { "raw": "inline with to a dn from lines", "markup": "markdown", "html": "<p>inline with to a dn from lines</p>", "type": "rendered" }, "created_on": "2019-09-27T00:33:46.039178+00:00", "user": { "display_name": "Name Lastname", "uuid": "{}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/%7B%7D" }, "html": { "href": "https://bitbucket.org/%7B%7D/" }, "avatar": { "href": "https://avatar-management--avatars.us-west-2.prod.public.atl-paas.net/:/128" } }, "type": "user", "nickname": "Name", "account_id": "" }, "created_on": "2019-09-27T00:33:46.039178+00:00", "user": { "display_name": "Name Lastname", "uuid": "{}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/%7B%7D" }, "html": { "href": "https://bitbucket.org/%7B%7D/" }, "avatar": { "href": "https://avatar-management--avatars.us-west-2.prod.public.atl-paas.net/:/128" } }, "type": "user", "nickname": "Name", "account_id": "" }, "updated_on": "2019-09-27T00:33:46.055384+00:00", "inline": { "context_lines": "", "to": null, "path": "", "outdated": false, "from": 211 }, "type": "pullrequest_comment", "id": 118571088 }, "pull_request": { "type": "pullrequest", "id": 5695, "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/pullrequests/5695" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/pull-requests/5695" } }, "title": "username/NONE: small change from onFocus to onClick to handle tabbing through the page and not expand the editor unless a click event triggers it" } } ] } ``` Updates include a state property of OPEN, MERGED, or DECLINED. Update example: ``` { "pagelen": 20, "values": [ { "update": { "description": "", "title": "username/NONE: small change from onFocus to onClick to handle tabbing through the page and not expand the editor unless a click event triggers it", "destination": { "commit": { "type": "commit", "hash": "6a2c16e4a152", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/commit/6a2c16e4a152" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/commits/6a2c16e4a152" } } }, "branch": { "name": "master" }, "repository": { "name": "Atlaskit-MK-2", "type": "repository", "full_name": "atlassian/atlaskit-mk-2", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2" }, "avatar": { "href": "https://bytebucket.org/ravatar/%7B%7D?ts=js" } }, "uuid": "{}" } }, "reason": "", "source": { "commit": { "type": "commit", "hash": "728c8bad1813", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/commit/728c8bad1813" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/commits/728c8bad1813" } } }, "branch": { "name": "username/NONE-add-onClick-prop-for-accessibility" }, "repository": { "name": "Atlaskit-MK-2", "type": "repository", "full_name": "atlassian/atlaskit-mk-2", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2" }, "avatar": { "href": "https://bytebucket.org/ravatar/%7B%7D?ts=js" } }, "uuid": "{}" } }, "state": "OPEN", "author": { "display_name": "Name Lastname", "uuid": "{}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/%7B%7D" }, "html": { "href": "https://bitbucket.org/%7B%7D/" }, "avatar": { "href": "https://avatar-management--avatars.us-west-2.prod.public.atl-paas.net/:/128" } }, "type": "user", "nickname": "Name", "account_id": "" }, "date": "2019-05-10T06:48:25.305565+00:00" }, "pull_request": { "type": "pullrequest", "id": 5695, "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/pullrequests/5695" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/pull-requests/5695" } }, "title": "username/NONE: small change from onFocus to onClick to handle tabbing through the page and not expand the editor unless a click event triggers it" } } ] } ``` Approval example: ``` { "pagelen": 20, "values": [ { "approval": { "date": "2019-09-27T00:37:19.849534+00:00", "pullrequest": { "type": "pullrequest", "id": 5695, "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/pullrequests/5695" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/pull-requests/5695" } }, "title": "username/NONE: small change from onFocus to onClick to handle tabbing through the page and not expand the editor unless a click event triggers it" }, "user": { "display_name": "Name Lastname", "uuid": "{}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/%7B%7D" }, "html": { "href": "https://bitbucket.org/%7B%7D/" }, "avatar": { "href": "https://avatar-management--avatars.us-west-2.prod.public.atl-paas.net/:/128" } }, "type": "user", "nickname": "Name", "account_id": "" } }, "pull_request": { "type": "pullrequest", "id": 5695, "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/atlaskit-mk-2/pullrequests/5695" }, "html": { "href": "https://bitbucket.org/atlassian/atlaskit-mk-2/pull-requests/5695" } }, "title": "username/NONE: small change from onFocus to onClick to handle tabbing through the page and not expand the editor unless a click event triggers it" } } ] } ```

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.

Returns a specific pull request comment.

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.

Redirects to the [repository file conflicts](/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-file-conflicts-spec-get) with the revspec that corresponds to the 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.

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.

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. ``` curl -X GET https://api.bitbucket.org/2.0/repositories/atlassian/bitbucket/pullrequests/2286/merge/task-status/<task_id> ``` If the merge task is not yet finished, a PENDING status will be returned. ``` HTTP/2 200 { "task_status": "PENDING", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bitbucket/pullrequests/2286/merge/task-status/<task_id>" } } } ``` If the merge was successful, a SUCCESS status will be returned. ``` HTTP/2 200 { "task_status": "SUCCESS", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bitbucket/pullrequests/2286/merge/task-status/<task_id>" } }, "merge_result": <the merged pull request object> } ``` If the merge task failed, an error will be returned. ``` { "type": "error", "error": { "message": "<error message>" } } ```

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.

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

Returns a paginated list of the pull request's tasks. This endpoint supports filtering and sorting of the results by the 'task' field. See [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) for more details.

Returns a specific pull request task.

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.

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: ``` curl -s https://api.bitbucket.org/2.0/repositories/atlassian/aui/refs/branches -G --data-urlencode 'q=name ~ "stab"' ``` 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.

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).

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.

Returns the specified tag. ``` $ curl -s https://api.bitbucket.org/2.0/repositories/seanfarley/hg/refs/tags/3.8 -G | jq . { "name": "3.8", "links": { "commits": { "href": "https://api.bitbucket.org/2.0/repositories/seanfarley/hg/commits/3.8" }, "self": { "href": "https://api.bitbucket.org/2.0/repositories/seanfarley/hg/refs/tags/3.8" }, "html": { "href": "https://bitbucket.org/seanfarley/hg/commits/tag/3.8" } }, "tagger": { "raw": "Matt Mackall <mpm@selenic.com>", "type": "author", "user": { "username": "mpmselenic", "nickname": "mpmselenic", "display_name": "Matt Mackall", "type": "user", "uuid": "{a4934530-db4c-419c-a478-9ab4964c2ee7}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/mpmselenic" }, "html": { "href": "https://bitbucket.org/mpmselenic/" }, "avatar": { "href": "https://bitbucket.org/account/mpmselenic/avatar/32/" } } } }, "date": "2016-05-01T18:52:25+00:00", "message": "Added tag 3.8 for changeset f85de28eae32", "type": "tag", "target": { "hash": "f85de28eae32e7d3064b1a1321309071bbaaa069", "repository": { "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/seanfarley/hg" }, "html": { "href": "https://bitbucket.org/seanfarley/hg" }, "avatar": { "href": "https://bitbucket.org/seanfarley/hg/avatar/32/" } }, "type": "repository", "name": "hg", "full_name": "seanfarley/hg", "uuid": "{c75687fb-e99d-4579-9087-190dbd406d30}" }, "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/seanfarley/hg/commit/f85de28eae32e7d3064b1a1321309071bbaaa069" }, "comments": { "href": "https://api.bitbucket.org/2.0/repositories/seanfarley/hg/commit/f85de28eae32e7d3064b1a1321309071bbaaa069/comments" }, "patch": { "href": "https://api.bitbucket.org/2.0/repositories/seanfarley/hg/patch/f85de28eae32e7d3064b1a1321309071bbaaa069" }, "html": { "href": "https://bitbucket.org/seanfarley/hg/commits/f85de28eae32e7d3064b1a1321309071bbaaa069" }, "diff": { "href": "https://api.bitbucket.org/2.0/repositories/seanfarley/hg/diff/f85de28eae32e7d3064b1a1321309071bbaaa069" }, "approve": { "href": "https://api.bitbucket.org/2.0/repositories/seanfarley/hg/commit/f85de28eae32e7d3064b1a1321309071bbaaa069/approve" }, "statuses": { "href": "https://api.bitbucket.org/2.0/repositories/seanfarley/hg/commit/f85de28eae32e7d3064b1a1321309071bbaaa069/statuses" } }, "author": { "raw": "Sean Farley <sean@farley.io>", "type": "author", "user": { "username": "seanfarley", "nickname": "seanfarley", "display_name": "Sean Farley", "type": "user", "uuid": "{a295f8a8-5876-4d43-89b5-3ad8c6c3c51d}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/seanfarley" }, "html": { "href": "https://bitbucket.org/seanfarley/" }, "avatar": { "href": "https://bitbucket.org/account/seanfarley/avatar/32/" } } } }, "parents": [ { "hash": "9a98d0e5b07fc60887f9d3d34d9ac7d536f470d2", "type": "commit", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/seanfarley/hg/commit/9a98d0e5b07fc60887f9d3d34d9ac7d536f470d2" }, "html": { "href": "https://bitbucket.org/seanfarley/hg/commits/9a98d0e5b07fc60887f9d3d34d9ac7d536f470d2" } } } ], "date": "2016-05-01T04:21:17+00:00", "message": "debian: alphabetize build deps", "type": "commit" } } ```

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)

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: ```javascript $ curl https://api.bitbucket.org/2.0/repositories/atlassian/bbql/src/eefd5ef/tests/__init__.py?format=meta { "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bbql/src/eefd5ef5d3df01aed629f650959d6706d54cd335/tests/__init__.py" }, "meta": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bbql/src/eefd5ef5d3df01aed629f650959d6706d54cd335/tests/__init__.py?format=meta" } }, "path": "tests/__init__.py", "commit": { "type": "commit", "hash": "eefd5ef5d3df01aed629f650959d6706d54cd335", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bbql/commit/eefd5ef5d3df01aed629f650959d6706d54cd335" }, "html": { "href": "https://bitbucket.org/atlassian/bbql/commits/eefd5ef5d3df01aed629f650959d6706d54cd335" } } }, "attributes": [], "type": "commit_file", "size": 0 } ``` 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: ```javascript $ curl https://api.bitbucket.org/2.0/repositories/atlassian/bbql/src/eefd5ef/tests { "pagelen": 10, "values": [ { "path": "tests/test_project", "type": "commit_directory", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bbql/src/eefd5ef5d3df01aed629f650959d6706d54cd335/tests/test_project/" }, "meta": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bbql/src/eefd5ef5d3df01aed629f650959d6706d54cd335/tests/test_project/?format=meta" } }, "commit": { "type": "commit", "hash": "eefd5ef5d3df01aed629f650959d6706d54cd335", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bbql/commit/eefd5ef5d3df01aed629f650959d6706d54cd335" }, "html": { "href": "https://bitbucket.org/atlassian/bbql/commits/eefd5ef5d3df01aed629f650959d6706d54cd335" } } } }, { "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bbql/src/eefd5ef5d3df01aed629f650959d6706d54cd335/tests/__init__.py" }, "meta": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bbql/src/eefd5ef5d3df01aed629f650959d6706d54cd335/tests/__init__.py?format=meta" } }, "path": "tests/__init__.py", "commit": { "type": "commit", "hash": "eefd5ef5d3df01aed629f650959d6706d54cd335", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bbql/commit/eefd5ef5d3df01aed629f650959d6706d54cd335" }, "html": { "href": "https://bitbucket.org/atlassian/bbql/commits/eefd5ef5d3df01aed629f650959d6706d54cd335" } } }, "attributes": [], "type": "commit_file", "size": 0 } ], "page": 1, "size": 2 } ``` 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.: ```javascript { "path": "tests/test_project", "type": "commit_directory", "links": { "self": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bbql/src/eefd5ef5d3df01aed629f650959d6706d54cd335/tests/test_project/" }, "meta": { "href": "https://api.bitbucket.org/2.0/repositories/atlassian/bbql/src/eefd5ef5d3df01aed629f650959d6706d54cd335/tests/test_project/?format=meta" } }, "commit": { ... } } ``` #### 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.

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

Returns the specified issue tracker version object.

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

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

Retrieve the URI of the content of the specified cache.

Retrieve the repository pipelines caches.

Retrieve the repository pipelines configuration.

Retrieve a repository level known host.

Find repository level known hosts.

Retrieve a schedule by its UUID.

Retrieve the executions of a given schedule.

Retrieve the configured schedules for the given repository.

Retrieve the repository SSH key pair excluding the SSH private key. The private key is a write only field and will never be exposed in the logs or the REST API.

Retrieve a repository level variable.

Find repository level variables.

Retrieve repository runner by uuid.

Retrieve repository runners.

**This endpoint is deprecated. Please use the [workspace scoped alternative](/cloud/bitbucket/rest/api-group-snippets/#api-snippets-workspace-get).** 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.

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.

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--

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.

Returns the specific snippet comment.

Returns the changes (commits) made on this snippet.

Returns the changes made on this snippet in this commit.

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.

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.

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.

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.

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.

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.

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

Returns the currently logged in user.

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

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.

**This endpoint is deprecated. Please use the [workspace scoped alternative](/cloud/bitbucket/rest/api-group-repositories/#api-user-workspaces-workspace-permissions-repositories-get).** 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`.

**This endpoint is deprecated. Please use the supported alternatives:** * [List workspaces for user](/cloud/bitbucket/rest/api-group-workspaces/#api-user-workspaces-get) * [Get user permission on a workspace](/cloud/bitbucket/rest/api-group-workspaces/#api-user-workspaces-workspace-permission-get) 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`.

Returns an object for each workspace accessible to the caller. This object also contains details on whether the caller has admin permissions on the workspace (`"administrator" = true`) or not (`"administrator" = false`). Queries support filtering based on administrator permissions, [sorting](/cloud/bitbucket/rest/intro/#sorting-query-results) or [filtering](/cloud/bitbucket/rest/intro/#filtering) by `slug`. Results can be [paginated](/cloud/bitbucket/rest/intro/#pagination).

Returns the caller's effective role; as in, the highest level of privilege the caller has for the workspace. If the calling user is a member of multiple groups with distinct roles, only the highest level is returned. Permissions can be: * `owner` * `create-project` * `collaborator` (deprecated; see this [deprecation announcement](/cloud/bitbucket/deprecation-notice-collaborator-role/) for more details) * `member`

Returns an object for each repository the caller has explicit access to in the specified workspace 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="bits"` or `q=permission>"read"` * `sort=repository.name` Note that the query parameter values need to be URL escaped so that `=` would become `%3D`.

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.

Returns a paginated list of the user's GPG public keys. The `key` and `subkeys` fields can also be requested from the endpoint. See [Partial Responses](/cloud/bitbucket/rest/intro/#partial-response) for more details.

Returns a specific GPG public key belonging to a user. The `key` and `subkeys` fields can also be requested from the endpoint. See [Partial Responses](/cloud/bitbucket/rest/intro/#partial-response) for more details.

Returns a paginated list of the user's SSH public keys.

Returns a specific SSH public key belonging to a user.

Get workspace runner by uuid.

Retrieve workspace runners.

**This endpoint is deprecated. Please use the [supported alternative](/cloud/bitbucket/rest/api-group-workspaces/#api-user-workspaces-get).** 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/).**

Returns the requested workspace.

Returns a paginated list of webhooks installed on this workspace.

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

Returns all members of the requested workspace. This endpoint additionally supports [filtering](/cloud/bitbucket/rest/intro/#filtering) by email address, if called by a workspace administrator, integration or workspace access token. This is done by adding the following query string parameter: * `q=user.email IN ("user1@org.com","user2@org.com")` When filtering by email, you can query up to 90 addresses at a time. Note that the query parameter values need to be URL escaped, so the final query string should be: * `q=user.email%20IN%20(%22user1@org.com%22,%22user2@org.com%22)` Email addresses that you filter by (and only these email addresses) can be included in the response using the `fields` query parameter: * `&fields=+values.user.email` - add the `email` field to the default `user` response object * `&fields=values.user.email,values.user.account_id` - only return user email addresses and account IDs Once again, all query parameter values must be URL escaped.

Returns the workspace membership, which includes a `User` object for the member and a `Workspace` object for the requested 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"`

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`.

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`.

Returns the list of projects in this workspace.

Returns the requested 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.

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. 4. `default_branch_deletion` indicates whether branches will be deleted by default on merge. 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.

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.

Returns the specified default reviewer.

Returns all deploy keys belonging to a project.

Returns the deploy key belonging to a specific key ID.

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

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`

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

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`

Returns all workspace 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.

Returns the system public GPG key(s). In most cases a single key is returned. During a key rotation period, two keys may be returned.

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: ``` $ curl -X POST -H "Content-Type: application/json" -d '{ "scm": "git", "project": { "key": "MARS" } }' https://api.bitbucket.org/2.0/repositories/teamsinspace/hablanding ``` or ``` $ curl -X POST -H "Content-Type: application/json" -d '{ "scm": "git", "project": { "key": "{ba516952-992a-4c2d-acbd-17d502922f96}" } }' https://api.bitbucket.org/2.0/repositories/teamsinspace/hablanding ``` 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.

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.

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.

Creates new comment on the specified commit. To post a reply to an existing comment, include the `parent.id` field: ``` $ curl https://api.bitbucket.org/2.0/repositories/atlassian/prlinks/commit/db9ba1e031d07a02603eae0e559a7adc010257fc/comments/ \ -X POST -u evzijst \ -H 'Content-Type: application/json' \ -d '{"content": {"raw": "One more thing!"}, "parent": {"id": 5728901}}' ```

Creates a new build status against the specified commit. If the specified key already exists, the existing status object will be overwritten. Example: ``` curl https://api.bitbucket.org/2.0/repositories/my-workspace/my-repo/commit/e10dae226959c2194f2b07b077c07762d93821cf/statuses/build/ -X POST -u jdoe -H 'Content-Type: application/json' -d '{ "key": "MY-BUILD", "state": "SUCCESSFUL", "description": "42 tests passed", "url": "https://www.example.org/my-build-result" }' ``` 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`. To associate a commit status to a pull request, the refname field must be set to the source branch of the pull request. Example: ``` curl https://api.bitbucket.org/2.0/repositories/my-workspace/my-repo/commit/e10dae226959c2194f2b07b077c07762d93821cf/statuses/build/ -X POST -u jdoe -H 'Content-Type: application/json' -d '{ "key": "MY-BUILD", "state": "SUCCESSFUL", "description": "42 tests passed", "url": "https://www.example.org/my-build-result", "refname": "my-pr-branch" }' ```

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.**

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.**

Create a new deploy key in a repository. Note: If authenticating a deploy key with an OAuth consumer, any changes to the OAuth consumer will subsequently invalidate the deploy key. Example: ``` $ curl -X POST \ -H "Authorization <auth header>" \ -H "Content-type: application/json" \ https://api.bitbucket.org/2.0/repositories/mleu/test/deploy-keys -d \ '{ "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDAK/b1cHHDr/TEV1JGQl+WjCwStKG6Bhrv0rFpEsYlyTBm1fzN0VOJJYn4ZOPCPJwqse6fGbXntEs+BbXiptR+++HycVgl65TMR0b5ul5AgwrVdZdT7qjCOCgaSV74/9xlHDK8oqgGnfA7ZoBBU+qpVyaloSjBdJfLtPY/xqj4yHnXKYzrtn/uFc4Kp9Tb7PUg9Io3qohSTGJGVHnsVblq/rToJG7L5xIo0OxK0SJSQ5vuId93ZuFZrCNMXj8JDHZeSEtjJzpRCBEXHxpOPhAcbm4MzULgkFHhAVgp4JbkrT99/wpvZ7r9AdkTg7HGqL3rlaDrEcWfL7Lu6TnhBdq5 mleu@C02W454JHTD8", "label": "mydeploykey" }' ```

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.

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: ``` $ curl -X POST -u jdoe https://api.bitbucket.org/2.0/repositories/atlassian/bbql/forks \ -H 'Content-Type: application/json' -d '{ "name": "bbql_fork", "workspace": { "slug": "atlassian" } }' ``` 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

Creates a new webhook on the specified repository. Example: ``` $ curl -X POST -u credentials -H 'Content-Type: application/json' https://api.bitbucket.org/2.0/repositories/my-workspace/my-repo-slug/hooks -d ' { "description": "Webhook Description", "url": "https://example.com/", "active": true, "secret": "this is a really bad secret", "events": [ "repo:push", "issue:created", "issue:updated" ] }' ``` When the `secret` is provided it will be used as the key to generate a HMAC digest value sent in the `X-Hub-Signature` header at delivery time. Passing a `null` or empty `secret` or not passing a `secret` will leave the webhook's secret unset. Bitbucket only generates the `X-Hub-Signature` when the webhook's secret is set. 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.

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.

A POST request to this endpoint initiates a new background celery task that archives the repo's issues. 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."

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: ``` $ curl -u <username> -X POST -F archive=@/path/to/file.zip https://api.bitbucket.org/2.0/repositories/<owner_username>/<repo_slug>/issues/import ```

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.

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: ``` curl https://api.bitbucket.org/2.0/site/master/issues/1234/changes \ -s -u evzijst -X POST -H "Content-Type: application/json" \ -d '{ "changes": { "assignee_account_id": { "new": "557058:c0b72ad0-1cb5-4018-9cdc-0cde8492c443" }, "state": { "new": 'resolved" } } "message": { "raw": "This is now resolved." } }' ``` 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.

Creates a new issue comment. ``` $ curl https://api.bitbucket.org/2.0/repositories/atlassian/prlinks/issues/42/comments/ \ -X POST -u evzijst \ -H 'Content-Type: application/json' \ -d '{"content": {"raw": "Lorem ipsum."}}' ```

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. ``` curl https://api.bitbucket.org/2.0/repositories/my-workspace/my-repository/pullrequests \ -u my-username:my-password \ --request POST \ --header 'Content-Type: application/json' \ --data '{ "title": "My Title", "source": { "branch": { "name": "staging" } } }' ``` 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`): ``` { "title": "My Title", "source": { "branch": { "name": "my-feature-branch" } }, "destination": { "branch": { "name": "staging" } } } ``` Reviewers can be specified by adding an array of user objects as the `reviewers` property. ``` { "title": "My Title", "source": { "branch": { "name": "my-feature-branch" } }, "reviewers": [ { "uuid": "{504c3b62-8120-4f0c-a7bc-87800b9d6f70}" } ] } ``` Other fields: * `description` - a string * `close_source_branch` - boolean that specifies if the source branch should be closed upon merging * `draft` - boolean that specifies whether the pull request is a draft

Approve the specified pull request as the authenticated user.

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

Resolve a comment thread

Declines the pull request.

Merges the pull request.

Request changes for a pull request

Creates a new pull request task. Returns the newly created pull request task. Tasks can optionally be created in relation to a comment specified by the comment's ID which will cause the task to appear below the comment on a pull request when viewed in Bitbucket.

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. ``` curl https://api.bitbucket.org/2.0/repositories/seanfarley/hg/refs/branches \ -s -u seanfarley -X POST -H "Content-Type: application/json" \ -d '{ "name" : "smf/create-feature", "target" : { "hash" : "default", } }' ``` 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.

Creates a new annotated 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. ``` curl https://api.bitbucket.org/2.0/repositories/jdoe/myrepo/refs/tags \ -s -u jdoe -X POST -H "Content-Type: application/json" \ -d '{ "name" : "new-tag-name", "target" : { "hash" : "a1b2c3d4e5f6", } }' ``` 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. A message for the tag object may optionally be provided. If it is omitted or the provided message is empty, a default message of "Added tag <tagname> for changeset <shorthash>" will be used.

This endpoint is used to create new commits in the repository by uploading files. To add a new file to a repository: ``` $ curl https://api.bitbucket.org/2.0/repositories/username/slug/src \ -F /repo/path/to/image.png=@image.png ``` 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: ``` $ curl https://api.bitbucket.org/2.0/repositories/username/slug/src \ -F files=/file/to/delete/1.txt \ -F files=/file/to/delete/2.txt ``` 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: ``` $ curl https://api.bitbucket.org/2.0/repositories/atlassian/bbql/src \ --data-urlencode "/path/to/me.txt=Lorem ipsum." \ --data-urlencode "message=Initial commit" \ --data-urlencode "author=Erik van Zijst <erik.van.zijst@gmail.com>" ``` 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`: ``` --===============1438169132528273974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-ID: "bin/shutdown.sh" Content-Disposition: attachment; filename="shutdown.sh"; x-attributes:"executable" #!/bin/sh halt --===============1438169132528273974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-ID: "/README.txt" Content-Disposition: attachment; filename="README.txt"; x-attributes:"link" README --===============1438169132528273974==-- ``` 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.

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).

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}`.

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`.

Adds a new GPG public key to the specified user account and returns the resulting key. Example: ``` $ curl -X POST -H "Content-Type: application/json" -d '{"key": "<insert GPG Key>"}' https://api.bitbucket.org/2.0/users/{d7dd0e2d-3994-4a50-a9ee-d260b6cefdab}/gpg-keys ```

Adds a new SSH public key to the specified user account and returns the resulting key. Example: ``` $ curl -X POST -H "Content-Type: application/json" -d '{"key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKqP3Cr632C2dNhhgKVcon4ldUSAeKiku2yP9O9/bDtY user@myhost"}' https://api.bitbucket.org/2.0/users/{ed08f5e1-605b-4f4a-aee4-6c97628a673e}/ssh-keys ```

Creates a new webhook on the specified workspace. Workspace webhooks are fired for events from all repositories contained by that workspace. Example: ``` $ curl -X POST -u credentials -H 'Content-Type: application/json' https://api.bitbucket.org/2.0/workspaces/my-workspace/hooks -d ' { "description": "Webhook Description", "url": "https://example.com/", "active": true, "secret": "this is a really bad secret", "events": [ "repo:push", "issue:created", "issue:updated" ] }' ``` When the `secret` is provided it will be used as the key to generate a HMAC digest value sent in the `X-Hub-Signature` header at delivery time. Passing a `null` or empty `secret` or not passing a `secret` will leave the webhook's secret unset. Bitbucket only generates the `X-Hub-Signature` when the webhook's secret is set. 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.

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: ``` $ body=$(cat << EOF { "name": "Mars Project", "key": "MARS", "description": "Software for colonizing mars.", "links": { "avatar": { "href": "data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOyDZu6QdvCchPGolfO0o/..." } }, "is_private": false } EOF ) $ curl -H "Content-Type: application/json" \ -X POST \ -d "$body" \ https://api.bitbucket.org/2.0/workspaces/teams-in-space/projects/ | jq . { // Serialized project document } ``` or even: ``` $ body=$(cat << EOF { "name": "Mars Project", "key": "MARS", "description": "Software for colonizing mars.", "links": { "avatar": { "href": "http://i.imgur.com/72tRx4w.gif" } }, "is_private": false } EOF ) $ curl -H "Content-Type: application/json" \ -X POST \ -d "$body" \ https://api.bitbucket.org/2.0/workspaces/teams-in-space/projects/ | jq . { // Serialized project document } ```

Create a new deploy key in a project. Example: ``` $ curl -X POST \ -H "Authorization <auth header>" \ -H "Content-type: application/json" \ https://api.bitbucket.org/2.0/workspaces/standard/projects/TEST_PROJECT/deploy-keys/ -d \ '{ "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDAK/b1cHHDr/TEV1JGQl+WjCwStKG6Bhrv0rFpEsYlyTBm1fzN0VOJJYn4ZOPCPJwqse6fGbXntEs+BbXiptR+++HycVgl65TMR0b5ul5AgwrVdZdT7qjCOCgaSV74/9xlHDK8oqgGnfA7ZoBBU+qpVyaloSjBdJfLtPY/xqj4yHnXKYzrtn/uFc4Kp9Tb7PUg9Io3qohSTGJGVHnsVblq/rToJG7L5xIo0OxK0SJSQ5vuId93ZuFZrCNMXj8JDHZeSEtjJzpRCBEXHxpOPhAcbm4MzULgkFHhAVgp4JbkrT99/wpvZ7r9AdkTg7HGqL3rlaDrEcWfL7Lu6TnhBdq5 mleu@C02W454JHTD8", "label": "mydeploykey" }' ```

Updates the application installation for the user. This endpoint is intended to be used by Bitbucket Connect apps and only supports JWT authentication -- that is how Bitbucket identifies the particular installation of the app. Developers with applications registered in the "Develop Apps" section of Bitbucket need not use this endpoint as updates for those applications can be sent out via the UI of that section. Passing an empty body will update the installation using the existing descriptor URL. ``` $ curl -X PUT https://api.bitbucket.org/2.0/addon \ -H "Authorization: JWT <JWT Token>" \ --header "Content-Type: application/json" \ --data '{}' ``` The new `descriptor` for the installation can be also provided in the body directly. ``` $ curl -X PUT https://api.bitbucket.org/2.0/addon \ -H "Authorization: JWT <JWT Token>" \ --header "Content-Type: application/json" \ --data '{"descriptor": $NEW_DESCRIPTOR}' ``` In both these modes the URL of the descriptor cannot be changed. To change the descriptor location and upgrade an installation the request must be made exclusively with a `descriptor_url`. ``` $ curl -X PUT https://api.bitbucket.org/2.0/addon \ -H "Authorization: JWT <JWT Token>" \ --header "Content-Type: application/json" \ --data '{"descriptor_url": $NEW_URL}' ``` The `descriptor_url` must exactly match the marketplace registration that Atlassian has for the application. Contact your Atlassian developer advocate to update this registration. Once the registration has been updated you may call this resource for each installation. Note that the scopes of the application cannot be increased in the new descriptor nor reduced to none.

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.

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.

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. The `default_branch_deletion` property is a string. The value of `true` indicates to delete branches by default. The value of `false` indicates that branches will not be deleted by default. A request without a `default_branch_deletion` property will leave it unchanged. Other values would be ignored. 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.

Used to update the contents of a comment. Only the content of the comment can be updated. ``` $ curl https://api.bitbucket.org/2.0/repositories/atlassian/prlinks/commit/7f71b5/comments/5728901 \ -X PUT -u evzijst \ -H 'Content-Type: application/json' \ -d '{"content": {"raw": "One more thing!"}' ```

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.

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.

Update an existing deploy key in a repository. The same key needs to be passed in but the comment and label can change. Example: ``` $ curl -X PUT \ -H "Authorization <auth header>" \ -H "Content-type: application/json" \ https://api.bitbucket.org/2.0/repositories/mleu/test/deploy-keys/1234 -d \ '{ "label": "newlabel", "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDAK/b1cHHDr/TEV1JGQl+WjCwStKG6Bhrv0rFpEsYlyTBm1fzN0VOJJYn4ZOPCPJwqse6fGbXntEs+BbXiptR+++HycVgl65TMR0b5ul5AgwrVdZdT7qjCOCgaSV74/9xlHDK8oqgGnfA7ZoBBU+qpVyaloSjBdJfLtPY/xqj4yHnXKYzrtn/uFc4Kp9Tb7PUg9Io3qohSTGJGVHnsVblq/rToJG7L5xIo0OxK0SJSQ5vuId93ZuFZrCNMXj8JDHZeSEtjJzpRCBEXHxpOPhAcbm4MzULgkFHhAVgp4JbkrT99/wpvZ7r9AdkTg7HGqL3rlaDrEcWfL7Lu6TnhBdq5 newcomment", }' ```

Updates the specified webhook subscription. The following properties can be mutated: * `description` * `url` * `secret` * `active` * `events` The hook's secret is used as a key to generate the HMAC hex digest sent in the `X-Hub-Signature` header at delivery time. This signature is only generated when the hook has a secret. Set the hook's secret by passing the new value in the `secret` field. Passing a `null` value in the `secret` field will remove the secret from the hook. The hook's secret can be left unchanged by not passing the `secret` field in the request.

Modifies the issue. ``` $ curl https://api.bitbucket.org/2.0/repostories/evzijst/dogslow/issues/123 \ -u evzijst -s -X PUT -H 'Content-Type: application/json' \ -d '{ "title": "Updated title", "assignee": { "account_id": "5d5355e8c6b9320d9ea5b28d" }, "priority": "minor", "version": { "name": "1.0" }, "component": null }' ``` 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.

Updates the content of the specified issue comment. Note that only the `content.raw` field can be modified. ``` $ curl https://api.bitbucket.org/2.0/repositories/atlassian/prlinks/issues/42/comments/5728901 \ -X PUT -u evzijst \ -H 'Content-Type: application/json' \ -d '{"content": {"raw": "Lorem ipsum."}' ```

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

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

Set the inheritance state for repository settings