How do AI agents use Bitbucket through Open Connector?

Your user connects Bitbucket once with one of its cataloged authentication methods. Open Connector stores the credential in an encrypted vault and exposes Bitbucket tools to your agent over MCP or a typed API, with credentials injected server-side on each call.

Is this a Bitbucket MCP server?

Yes. Open Connector can serve Bitbucket as a named MCP server with a scoped allowlist and a per-user connection URL, so any MCP client can call Bitbucket actions with credentials injected server-side.

Where do Bitbucket credentials live?

In your own infrastructure. Open Connector keeps credentials in its own vault and injects them at call time, so they never leave your environment.

Bitbucket integration

Bitbucket integration for AI agents.

Bitbucket integration for AI agents with secure authentication and server-side credential injection. Open Connector runs the OAuth, seals the token in an encrypted vault, and serves Bitbucket tools to your agent over MCP or a typed API — credentials injected server-side, every call audited, nothing leaving your infrastructure. Open source (AGPL-3.0) and self-hostable.

View source on GitHub All integrations →

What your agents can do

Real Bitbucket actions, managed and audited.

Your user connects Bitbucket once; your agent can then manage Bitbucket Cloud repositories, pipelines, pull requests, issues, and workspaces — scoped to the OAuth permissions you grant and the tool allowlist you configure. Every action is least-privilege and written to a tamper-evident audit trail.

1
Your user grants Bitbucket access once (OAuth) — the token lands in the vault.
2
Your agent calls a tool over MCP or the typed API; Open Connector injects the credential server-side.
3
Every routed call appends a hash-chained audit record — nothing leaves your infra.

Tools & triggers

Supported Bitbucket tools.

331 tools are generated from the published Bitbucket catalog. Descriptions are plain text; each action remains subject to its configured authentication and tool allowlist.

Showing 331 tools. All published catalog entries are included in this page's server-rendered HTML.

Bulk create or update annotations: Bulk upload of annotations. Annotations are individual findings that have been identified as part of a report, for example, a line of code that represents a vulnerability. These annotations can be attached to a specific file and even a specific line in that file, however, that is optional. Annotations are not mandatory and a report can contain up to 1000 annotations. Add the annotations you want to upload as objects in a JSON array and make sure each annotation has the external_id field set to a unique value. If you want to use an existing id from your own system, we recommend prefixing it with your system's name to avoid collisions, for example, mySystem-annotation001. The external id can later be used to identify the report as an alternative to the generated [UUID](https://developer.atlassian.com/bitbucket/api/2/reference/meta/uri-uuid#uuid). You can upload up to 100 annotations per POST request. ### Sample cURL request: ``` 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.; ReportsCommits
Create a variable for an environment: Create a deployment environment level variable.; Pipelines
Create an environment: Create an environment.; Deployments
Create or update an annotation: Creates or updates an individual annotation for the specified report. Annotations are individual findings that have been identified as part of a report, for example, a line of code that represents a vulnerability. These annotations can be attached to a specific file and even a specific line in that file, however, that is optional. Annotations are not mandatory and a report can contain up to 1000 annotations. Just as reports, annotation needs to be uploaded with a unique ID that can later be used to identify the report as an alternative to the generated [UUID](https://developer.atlassian.com/bitbucket/api/2/reference/meta/uri-uuid#uuid). If you want to use an existing id from your own system, we recommend prefixing it with your system's name to avoid collisions, for example, mySystem-annotation001. ### Sample cURL request: ``` 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.; ReportsCommits
Create or update a report: Creates or updates a report for the specified commit. To upload a report, make sure to generate an ID that is unique across all reports for that commit. If you want to use an existing id from your own system, we recommend prefixing it with your system's name to avoid collisions, for example, mySystem-001. ### Sample cURL request: ``` 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.; ReportsCommits
Run a pipeline: 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' ```; Pipelines
Create a variable for a user: Create an account level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).; Pipelines
Create a variable for a user: Create a user level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).; Pipelines
Create a variable for a workspace: Create a workspace level variable.; Pipelines
Create a known host: Create a repository level known host.; Pipelines
Create a schedule: Create a schedule for the given repository.; Pipelines
Create a variable for a repository: Create a repository level variable.; Pipelines
Create repository runner: Create repository runner.; Pipelines
Create workspace runner: Create workspace runner.; Pipelines
Delete an app: 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>" ```; Addon
Delete an annotation: Deletes a single Annotation matching the provided ID.; ReportsCommits
Delete a commit application property: Delete an [application property](/cloud/bitbucket/application-properties/) value stored against a commit.; properties
Delete a variable for an environment: Delete a deployment environment level variable.; Pipelines
Delete an environment: Delete an environment; Deployments
Delete a variable for a team: Delete a team level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).; Pipelines
Delete a variable for a user: Delete an account level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).; Pipelines
Delete a variable for a workspace: Delete a workspace level variable.; Pipelines
Delete a pull request application property: Delete an [application property](/cloud/bitbucket/application-properties/) value stored against a pull request.; properties
Delete a report: Deletes a single Report matching the provided ID.; ReportsCommits
Delete a repository: Deletes the repository. This is an irreversible operation. This does not affect its forks.; Repositories
Delete a branch restriction rule: Deletes an existing branch restriction rule.; Branch restrictions
Unapprove a commit: Redact the authenticated user's approval of the specified commit. This operation is only available to users that have explicit access to the repository. In contrast, just the fact that a repository is publicly accessible to users does not give them the ability to approve commits.; Commits
Delete a commit comment: Deletes the specified commit comment. Note that deleting comments that have visible replies that point to them will not really delete the resource. This is to retain the integrity of the original comment tree. Instead, the `deleted` element is set to `true` and the content is blanked out. The comment will continue to be returned by the collections and self endpoints.; Commits
Remove a user from the default reviewers: Removes a default reviewer from the repository.; Pullrequests
Delete a repository deploy key: This deletes a deploy key from a repository.; Deployments
Delete a download artifact: Deletes the specified download artifact from the repository.; Downloads
Delete a webhook for a repository: Deletes the specified webhook subscription from the given repository.; RepositoriesWebhooks
Delete an issue: Deletes the specified issue. This requires write access to the repository.; Issue tracker
Delete an attachment for an issue: Deletes an attachment.; Issue tracker
Delete a comment on an issue: Deletes the specified comment.; Issue tracker
Remove vote for an issue: Retract your vote.; Issue tracker
Stop watching an issue: Stop watching this issue.; Issue tracker
Delete an explicit group permission for a repository: Deletes the repository group permission between the requested repository and group, if one exists. Only users with admin permission for the repository may access this resource. The only authentication method supported for this endpoint is via app passwords.; Repositories
Delete an explicit user permission for a repository: Deletes the repository user permission between the requested repository and user, if one exists. Only users with admin permission for the repository may access this resource. The only authentication method for this endpoint is via app passwords.; Repositories
Unapprove a pull request: Redact the authenticated user's approval of the specified pull request.; Pullrequests
Delete a comment on a pull request: Deletes a specific pull request comment.; Pullrequests
Reopen a comment thread: Reopen a comment thread; Pullrequests
Remove change request for a pull request: Remove change request for a pull request; Pullrequests
Delete a task on a pull request: Deletes a specific pull request task.; Pullrequests
Delete a branch: Delete a branch in the specified repository. The main branch is not allowed to be deleted and will return a 400 response. The branch name should not include any prefixes (e.g. refs/heads).; Refs
Delete a tag: Delete a tag in the specified repository. The tag name should not include any prefixes (e.g. refs/tags).; Refs
Delete a repository application property: Delete an [application property](/cloud/bitbucket/application-properties/) value stored against a repository.; properties
Delete a cache: Delete a repository cache.; Pipelines
Delete caches: Delete repository cache versions by name.; Pipelines
Delete SSH key pair: Delete the repository SSH key pair.; Pipelines
Delete a known host: Delete a repository level known host.; Pipelines
Delete a schedule: Delete a schedule.; Pipelines
Delete a variable for a repository: Delete a repository level variable.; Pipelines
Delete repository runner: Delete repository runner by uuid.; Pipelines
Delete a snippet: Deletes a snippet and returns an empty response.; Snippets
Delete a comment on a snippet: Deletes a snippet comment. Comments can only be removed by the comment author, snippet creator, or workspace admin.; Snippets
Delete a previous revision of a snippet: Deletes the snippet. Note that this only works for versioned URLs that point to the latest commit of the snippet. Pointing to an older commit results in a 405 status code. To delete a snippet, regardless of whether or not concurrent changes are being made to it, use `DELETE /snippets/{encoded_id}` instead.; Snippets
Stop watching a snippet: Used to stop watching a specific snippet. Returns 204 (No Content) to indicate success.; Snippets
Delete a user application property: Delete an [application property](/cloud/bitbucket/application-properties/) value stored against a user.; properties
Delete a GPG key: Deletes a specific GPG public key from a user's account.; GPG
Delete a SSH key: Deletes a specific SSH public key from a user's account.; SSH
Delete workspace runner: Delete workspace runner by uuid.; Pipelines
Delete a webhook for a workspace: Deletes the specified webhook subscription from the given workspace.; WorkspacesWebhooks
Delete a project for a workspace: Deletes this project. This is an irreversible operation. You cannot delete a project that still contains repositories. To delete the project, [delete](/cloud/bitbucket/rest/api-group-repositories/#api-repositories-workspace-repo-slug-delete) or transfer the repositories first. Example: ``` $ curl -X DELETE https://api.bitbucket.org/2.0/workspaces/bbworkspace1/projects/PROJ ```; Projects
Remove the specific user from the project's default reviewers: 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 ```; Projects
Delete a deploy key from a project: This deletes a deploy key from a project.; Deployments
Delete an explicit group permission for a project: Deletes the project group permission between the requested project and group, if one exists. Only users with admin permission for the project may access this resource.; Projects
Delete an explicit user permission for a project: Deletes the project user permission between the requested project and user, if one exists. Only users with admin permission for the project may access this resource. Due to security concerns, the JWT and OAuth authentication methods are unsupported. This is to ensure integrations and add-ons are not allowed to change permissions.; Projects
Get the client key of a Connect addon: 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`) ```; Addon
Get an annotation: Returns a single Annotation matching the provided ID.; ReportsCommits
List annotations: Returns a paginated list of Annotations for a specified report.; ReportsCommits
Get a commit application property: Retrieve an [application property](/cloud/bitbucket/application-properties/) value stored against a commit.; properties
Get a deployment: Retrieve a deployment; Deployments
List variables for an environment: Find deployment environment level variables.; Pipelines
List deployments: Find deployments; Deployments
Get an environment: Retrieve an environment; Deployments
List environments: Find environments; Deployments
Get a webhook resource: Returns the webhook resource or subject types on which webhooks can be registered. Each resource/subject type contains an `events` link that returns the paginated list of specific events each individual subject type can emit. This endpoint is publicly accessible and does not require authentication or scopes.; Webhooks
List subscribable webhook types: Returns a paginated list of all valid webhook events for the specified entity. **The team and user webhooks are deprecated, and you should use workspace instead. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).** This is public data that does not require any scopes or authentication. NOTE: The example response is a truncated response object for the `workspace` `subject_type`. We return the same structure for the other `subject_type` objects.; Webhooks
Get OpenID configuration for OIDC in Pipelines: This is part of OpenID Connect for Pipelines, see https://support.atlassian.com/bitbucket-cloud/docs/integrate-pipelines-with-resource-servers-using-oidc/; Pipelines
Get keys for OIDC in Pipelines: This is part of OpenID Connect for Pipelines, see https://support.atlassian.com/bitbucket-cloud/docs/integrate-pipelines-with-resource-servers-using-oidc/; Pipelines
Get the logs for the build container or a service container for a given step of a pipeline.: Retrieve the log file for a build container or service container. This endpoint supports (and encourages!) the use of [HTTP Range requests](https://tools.ietf.org/html/rfc7233) to deal with potentially very large log files.; Pipelines
Get a pipeline: Retrieve a specified pipeline; Pipelines
Get a step of a pipeline: Retrieve a given step of a pipeline.; Pipelines
Get log file for a step: Retrieve the log file for a given step of a pipeline. This endpoint supports (and encourages!) the use of [HTTP Range requests](https://tools.ietf.org/html/rfc7233) to deal with potentially very large log files.; Pipelines
List steps for a pipeline: Find steps for the given pipeline.; Pipelines
Get test case reasons (output) for a given test case in a step of a pipeline.: Get test case reasons (output) for a given test case in a step of a pipeline.; Pipelines
Get test cases for a given step of a pipeline.: Get test cases for a given step of a pipeline.; Pipelines
Get a summary of test reports for a given step of a pipeline.: Get a summary of test reports for a given step of a pipeline.; Pipelines
Get a variable for a team: Retrieve a team level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).; Pipelines
Get a variable for a user: Retrieve a user level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).; Pipelines
Get variable for a workspace: Retrieve a workspace level variable.; Pipelines
List variables for an account: Find account level variables. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).; Pipelines
List variables for a user: Find user level variables. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).; Pipelines
List variables for a workspace: Find workspace level variables.; Pipelines
List pipelines: 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.; Pipelines
Get a pull request application property: Retrieve an [application property](/cloud/bitbucket/application-properties/) value stored against a pull request.; properties
List pull requests that contain a commit: Returns a paginated list of all pull requests as part of which this commit was reviewed. Pull Request Commit Links app must be installed first before using this API; installation automatically occurs when 'Go to pull request' is clicked from the web interface for a commit's details.; Pullrequests
Get a report: Returns a single Report matching the provided ID.; ReportsCommits
List reports: Returns a paginated list of Reports linked to this commit.; ReportsCommits
List public repositories: **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.; Repositories
List repositories in a workspace: Returns a paginated list of all repositories owned by the specified workspace. The result can be narrowed down based on the authenticated user's role. E.g. with `?role=contributor`, only those repositories that the authenticated user has write access to are returned (this includes any repo the user is an admin on, as that implies write access). This endpoint also supports filtering and sorting of the results. See [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) for more details.; Repositories
Get a repository: Returns the object describing this repository.; Repositories
List branch restrictions: Returns a paginated list of all branch restrictions on the repository.; Branch restrictions
Get a branch restriction rule: Returns a specific branch restriction rule.; Branch restrictions
Get the branching model for a repository: Return the branching model as applied to the repository. This view is read-only. The branching model settings can be changed using the [settings](#api-repositories-workspace-repo-slug-branching-model-settings-get) API. The returned object: 1. Always has a `development` property. `development.branch` contains the actual repository branch object that is considered to be the `development` branch. `development.branch` will not be present if it does not exist. 2. Might have a `production` property. `production` will not be present when `production` is disabled. `production.branch` contains the actual branch object that is considered to be the `production` branch. `production.branch` will not be present if it does not exist. 3. Always has a `branch_types` array which contains all enabled branch types.; Branching model
Get the branching model config for a repository: Return the branching model configuration for a repository. The returned object: 1. Always has a `development` property for the development branch. 2. Always a `production` property for the production branch. The production branch can be disabled. 3. The `branch_types` contains all the branch types. 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.; Branching model
Get a commit: Returns the specified commit.; Commits
List a commit's comments: Returns the commit's comments. This includes both global and inline comments. The default sorting is oldest to newest and can be overridden with the `sort` query parameter.; Commits
Get a commit comment: Returns the specified commit comment.; Commits
List commit statuses for a commit: Returns all statuses (e.g. build results) for a specific commit.; Commit statuses
Get a build status for a commit: Returns the specified build status for a commit.; Commit statuses
List commits: These are the repository's commits. They are paginated and returned in reverse chronological order, similar to the output of `git log`. Like these tools, the DAG can be filtered. #### GET /repositories/{workspace}/{repo_slug}/commits/ Returns all commits in the repo in topological order (newest commit first). All branches and tags are included (similar to `git log --all`). #### GET /repositories/{workspace}/{repo_slug}/commits/?exclude=master Returns all commits in the repo that are not on master (similar to `git log --all ^master`). #### GET /repositories/{workspace}/{repo_slug}/commits/?include=foo&include=bar&exclude=fu&exclude=fubar Returns all commits that are on refs `foo` or `bar`, but not on `fu` or `fubar` (similar to `git log foo bar ^fu ^fubar`). An optional `path` parameter can be specified that will limit the results to commits that affect that path. `path` can either be a file or a directory. If a directory is specified, commits are returned that have modified any file in the directory tree rooted by `path`. It is important to note that if the `path` parameter is specified, the commits returned by this endpoint may no longer be a DAG, parent commits that do not modify the path will be omitted from the response. #### GET /repositories/{workspace}/{repo_slug}/commits/?path=README.md&include=foo&include=bar&exclude=master Returns all commits that are on refs `foo` or `bar`, but not on `master` that changed the file README.md. #### GET /repositories/{workspace}/{repo_slug}/commits/?path=src/&include=foo&include=bar&exclude=master Returns all commits that are on refs `foo` or `bar`, but not on `master` that changed to a file in any file in the directory src or its children. Because the response could include a very large number of commits, it is paginated. Follow the 'next' link in the response to navigate to the next page of commits. As with other paginated resources, do not construct your own links. When the include and exclude parameters are more than can fit in a query string, clients can use a `x-www-form-urlencoded` POST instead.; Commits
List commits for revision: These are the repository's commits. They are paginated and returned in reverse chronological order, similar to the output of `git log`. Like these tools, the DAG can be filtered. #### GET /repositories/{workspace}/{repo_slug}/commits/master Returns all commits on ref `master` (similar to `git log master`). #### GET /repositories/{workspace}/{repo_slug}/commits/dev?include=foo&exclude=master Returns all commits on ref `dev` or `foo`, except those that are reachable on `master` (similar to `git log dev foo ^master`). An optional `path` parameter can be specified that will limit the results to commits that affect that path. `path` can either be a file or a directory. If a directory is specified, commits are returned that have modified any file in the directory tree rooted by `path`. It is important to note that if the `path` parameter is specified, the commits returned by this endpoint may no longer be a DAG, parent commits that do not modify the path will be omitted from the response. #### GET /repositories/{workspace}/{repo_slug}/commits/dev?path=README.md&include=foo&include=bar&exclude=master Returns all commits that are on refs `dev` or `foo` or `bar`, but not on `master` that changed the file README.md. #### GET /repositories/{workspace}/{repo_slug}/commits/dev?path=src/&include=foo&exclude=master Returns all commits that are on refs `dev` or `foo`, but not on `master` that changed to a file in any file in the directory src or its children. Because the response could include a very large number of commits, it is paginated. Follow the 'next' link in the response to navigate to the next page of commits. As with other paginated resources, do not construct your own links. When the include and exclude parameters are more than can fit in a query string, clients can use a `x-www-form-urlencoded` POST instead.; Commits
List components: Returns the components that have been defined in the issue tracker. This resource is only available on repositories that have the issue tracker enabled.; Issue tracker
Get a component for issues: Returns the specified issue tracker component object.; Issue tracker
List default reviewers: Returns the repository's default reviewers. These are the users that are automatically added as reviewers on every new pull request that is created. To obtain the repository's default reviewers as well as the default reviewers inherited from the project, use the [effective-default-reveiwers](#api-repositories-workspace-repo-slug-effective-default-reviewers-get) endpoint.; Pullrequests
Get a default reviewer: Returns the specified reviewer. This can be used to test whether a user is among the repository's default reviewers list. A 404 indicates that that specified user is not a default reviewer.; Pullrequests
List repository deploy keys: Returns all deploy-keys belonging to a repository.; Deployments
Get a repository deploy key: Returns the deploy key belonging to a specific key.; Deployments
Compare two commits: Produces a raw git-style diff. #### Single commit spec If the `spec` argument to this API is a single commit, the diff is produced against the first parent of the specified commit. #### Two commit spec Two commits separated by `..` may be provided as the `spec`, e.g., `3a8b42..9ff173`. When two commits are provided and the `topic` query parameter is true, this API produces a 2-way three dot diff. This is the diff between source commit and the merge base of the source commit and the destination commit. When the `topic` query param is false, a simple git-style diff is produced. The two commits are interpreted as follows: * First commit: the commit containing the changes we wish to preview * Second commit: the commit representing the state to which we want to compare the first commit * **Note**: This is the opposite of the order used in `git diff`. #### Comparison to patches While similar to patches, diffs: * Don't have a commit header (username, commit message, etc) * Support the optional `path=foo/bar.py` query param to filter the diff to just that one file diff #### Response The raw diff is returned as-is, in whatever encoding the files in the repository use. It is not decoded into unicode. As such, the content-type is `text/plain`.; Commits
Compare two commit diff stats: Produces a response in JSON format with a record for every path modified, including information on the type of the change and the number of lines added and removed. #### Single commit spec If the `spec` argument to this API is a single commit, the diff is produced against the first parent of the specified commit. #### Two commit spec Two commits separated by `..` may be provided as the `spec`, e.g., `3a8b42..9ff173`. When two commits are provided and the `topic` query parameter is true, this API produces a 2-way three dot diff. This is the diff between source commit and the merge base of the source commit and the destination commit. When the `topic` query param is false, a simple git-style diff is produced. The two commits are interpreted as follows: * First commit: the commit containing the changes we wish to preview * Second commit: the commit representing the state to which we want to compare the first commit * **Note**: This is the opposite of the order used in `git diff`.; Commits
List download artifacts: Returns a list of download links associated with the repository.; Downloads
Get a download artifact link: Return a redirect to the contents of a download artifact. This endpoint returns the actual file contents and not the artifact's metadata. $ curl -s -L https://api.bitbucket.org/2.0/repositories/evzijst/git-tests/downloads/hello.txt Hello World; Downloads
Get the effective, or currently applied, branching model for a repository: Get the effective, or currently applied, branching model for a repository; Branching model
List effective default reviewers: Returns the repository's effective default reviewers. This includes both default reviewers defined at the repository level as well as those inherited from its project. These are the users that are automatically added as reviewers on every new pull request that is created.; Pullrequests
Get file conflicts for a commit spec: Get file conflicts for a commit spec; Commits
List commits that modified a file: Returns a paginated list of commits that modified the specified file. Commits are returned in reverse chronological order. This is roughly equivalent to the following commands: $ git log --follow --date-order <sha> <path> By default, Bitbucket will follow renames and the path name in the returned entries reflects that. This can be turned off using the `?renames=false` query parameter. Results are returned in descending chronological order by default, and like most endpoints you can [filter and sort](/cloud/bitbucket/rest/intro/#filtering) the response to only provide exactly the data you want. 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`.; SourceRepositories
List repository forks: Returns a paginated list of all the forks of the specified repository.; Repositories
List webhooks for a repository: Returns a paginated list of webhooks installed on this repository.; RepositoriesWebhooks
Get a webhook for a repository: Returns the webhook with the specified id installed on the specified repository.; RepositoriesWebhooks
List issues: Returns the issues in the issue tracker.; Issue tracker
Check issue export status: This endpoint is used to poll for the progress of an issue export job and return the zip file after the job is complete. As long as the job is running, this will return a 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`.; Issue tracker
Check issue import status: 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`.; Issue tracker
Get an issue: Returns the specified issue.; Issue tracker
List attachments for an issue: Returns all attachments for this issue. This returns the files' meta data. This does not return the files' actual contents. The files are always ordered by their upload date.; Issue tracker
Get attachment for an issue: Returns the contents of the specified file attachment. Note that this endpoint does not return a JSON response, but instead returns a redirect pointing to the actual file that in turn will return the raw contents. The redirect URL contains a one-time token that has a limited lifetime. As a result, the link should not be persisted, stored, or shared.; Issue tracker
List changes on an issue: Returns the list of all changes that have been made to the specified issue. Changes are returned in chronological order with the oldest change first. Each time an issue is edited in the UI or through the API, an immutable change record is created under the `/issues/123/changes` endpoint. It also has a comment associated with the change. Note that this operation is changing significantly, due to privacy changes. See the [announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-changes-gdpr/#changes-to-the-issue-changes-api) for details. Changes support [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) that can be used to search for specific changes. For instance, to see when an issue transitioned to "resolved": ``` $ 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.; Issue tracker
Get issue change object: Returns the specified issue change object. This resource is only available on repositories that have the issue tracker enabled.; Issue tracker
List comments on an issue: Returns a paginated list of all comments that were made on the specified issue. The default sorting is oldest to newest and can be overridden with the `sort` query parameter. This endpoint also supports filtering and sorting of the results. See [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) for more details.; Issue tracker
Get a comment on an issue: Returns the specified issue comment object.; Issue tracker
Check if current user voted for an issue: Check whether the authenticated user has voted for this issue. A 204 status code indicates that the user has voted, while a 404 implies they haven't.; Issue tracker
Check if current user is watching a issue: Indicated whether or not the authenticated user is watching this issue.; Issue tracker
Get the common ancestor between two commits: Returns the best common ancestor between two commits, specified in a revspec of 2 commits (e.g. 3a8b42..9ff173). If more than one best common ancestor exists, only one will be returned. It is unspecified which will be returned.; Commits
List milestones: Returns the milestones that have been defined in the issue tracker. This resource is only available on repositories that have the issue tracker enabled.; Issue tracker
Get a milestone: Returns the specified issue tracker milestone object.; Issue tracker
Retrieve the inheritance state for repository settings: Retrieve the inheritance state for repository settings; Repositories
Get a patch for two commits: Produces a raw patch for a single commit (diffed against its first parent), or a patch-series for a revspec of 2 commits (e.g. `3a8b42..9ff173` where the first commit represents the source and the second commit the destination). In case of the latter (diffing a revspec), a patch series is returned for the commits on the source branch (`3a8b42` and its ancestors in our example). While similar to diffs, patches: * Have a commit header (username, commit message, etc) * Do not support the `path=foo/bar.py` query parameter The raw patch is returned as-is, in whatever encoding the files in the repository use. It is not decoded into unicode. As such, the content-type is `text/plain`.; Commits
List explicit group permissions for a repository: Returns a paginated list of explicit group permissions for the given repository. This endpoint does not support BBQL features.; Repositories
Get an explicit group permission for a repository: Returns the group permission for a given group slug and repository Only users with admin permission for the repository may access this resource. Permissions can be: * `admin` * `write` * `read` * `none`; Repositories
List explicit user permissions for a repository: Returns a paginated list of explicit user permissions for the given repository. This endpoint does not support BBQL features.; Repositories
Get an explicit user permission for a repository: Returns the explicit user permission for a given user and repository. Only users with admin permission for the repository may access this resource. Permissions can be: * `admin` * `write` * `read` * `none`; Repositories
List pull requests: Returns all pull requests on the specified repository. By default only open pull requests are returned. This can be controlled using the `state` query parameter. To retrieve pull requests that are in one of multiple states, repeat the `state` parameter for each individual state. This endpoint also supports filtering and sorting of the results. See [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) for more details.; Pullrequests
List a pull request activity log: Returns a paginated list of the pull request's activity log. This handler serves both a v20 and internal endpoint. The v20 endpoint returns reviewer comments, updates, approvals and request changes. The internal endpoint includes those plus tasks and attachments. Comments created on a file or a line of code have an inline property. Comment example: ``` { "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" } } ] } ```; Pullrequests
Get a pull request: Returns the specified pull request.; Pullrequests
List a pull request activity log: Returns a paginated list of the pull request's activity log. This handler serves both a v20 and internal endpoint. The v20 endpoint returns reviewer comments, updates, approvals and request changes. The internal endpoint includes those plus tasks and attachments. Comments created on a file or a line of code have an inline property. Comment example: ``` { "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" } } ] } ```; Pullrequests
List comments on a pull request: Returns a paginated list of the pull request's comments. This includes both global, inline comments and replies. The default sorting is oldest to newest and can be overridden with the `sort` query parameter. This endpoint also supports filtering and sorting of the results. See [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) for more details.; Pullrequests
Get a comment on a pull request: Returns a specific pull request comment.; Pullrequests
List commits on a pull request: Returns a paginated list of the pull request's commits. These are the commits that are being merged into the destination branch when the pull requests gets accepted.; Pullrequests
Get file conflicts for a pull request: 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.; Pullrequests
List changes in a pull request: Redirects to the [repository diff](/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-diff-spec-get) with the revspec that corresponds to the pull request.; Pullrequests
Get the diff stat for a pull request: Redirects to the [repository diffstat](/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-diffstat-spec-get) with the revspec that corresponds to the pull request.; Pullrequests
Get the merge task status for a pull request: When merging a pull request takes too long, the client receives a task ID along with a 202 status code. The task ID can be used in a call to this endpoint to check the status of a merge task. ``` 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>" } } ```; Pullrequests
Get the patch for a pull request: Redirects to the [repository patch](/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-patch-spec-get) with the revspec that corresponds to pull request.; Pullrequests
List commit statuses for a pull request: Returns all statuses (e.g. build results) for the given pull request.; PullrequestsCommit statuses
List tasks on a 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.; Pullrequests
Get a task on a pull request: Returns a specific pull request task.; Pullrequests
List branches and tags: Returns the branches and tags in the repository. By default, results will be in the order the underlying source control system returns them and identical to the ordering one sees when running "$ git show-ref". Note that this follows simple lexical ordering of the ref names. This can be undesirable as it does apply any natural sorting semantics, meaning for instance that refs are sorted ["branch1", "branch10", "branch2", "v10", "v11", "v9"] instead of ["branch1", "branch2", "branch10", "v9", "v10", "v11"]. Sorting can be changed using the ?sort= query parameter. When using ?sort=name to explicitly sort on ref name, Bitbucket will apply natural sorting and interpret numerical values as numbers instead of strings.; Refs
List open branches: Returns a list of all open branches within the specified repository. Results will be in the order the source control manager returns them. Branches support [filtering and sorting](/cloud/bitbucket/rest/intro/#filtering) that can be used to search for specific branches. For instance, to find all branches that have "stab" in their name: ``` 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.; Refs
Get a branch: Returns a branch object within the specified repository. This call requires authentication. Private repositories require the caller to authenticate with an account that has appropriate authorization. For Git, the branch name should not include any prefixes (e.g. refs/heads).; Refs
List tags: Returns the tags in the repository. By default, results will be in the order the underlying source control system returns them and identical to the ordering one sees when running "$ git tag --list". Note that this follows simple lexical ordering of the ref names. This can be undesirable as it does apply any natural sorting semantics, meaning for instance that tags are sorted ["v10", "v11", "v9"] instead of ["v9", "v10", "v11"]. Sorting can be changed using the ?sort= query parameter. When using ?sort=name to explicitly sort on ref name, Bitbucket will apply natural sorting and interpret numerical values as numbers instead of strings.; Refs
Get a tag: 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" } } ```; Refs
Get the root directory of the main branch: This endpoint redirects the client to the directory listing of the root directory on the main branch. This is equivalent to directly hitting [/2.0/repositories/{username}/{repo_slug}/src/{commit}/{path}](src/%7Bcommit%7D/%7Bpath%7D) without having to know the name or SHA1 of the repo's main branch. To create new commits, [POST to this endpoint](#post); SourceRepositories
Get file or directory contents: This endpoints is used to retrieve the contents of a single file, or the contents of a directory at a specified revision. #### Raw file contents When `path` points to a file, this endpoint returns the raw contents. The response's Content-Type is derived from the filename extension (not from the contents). The file contents are not processed and no character encoding/recoding is performed and as a result no character encoding is included as part of the Content-Type. The `Content-Disposition` header will be "attachment" to prevent browsers from running executable files. If the file is managed by LFS, then a 301 redirect pointing to Atlassian's media services platform is returned. The response includes an ETag that is based on the contents of the file and its attributes. This means that an empty `__init__.py` always returns the same ETag, regardless on the directory it lives in, or the commit it is on. #### File meta data When the request for a file path includes the query parameter `?format=meta`, instead of returning the file's raw contents, Bitbucket instead returns the JSON object describing the file's properties: ```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.; SourceRepositories
List defined versions for issues: Returns the versions that have been defined in the issue tracker. This resource is only available on repositories that have the issue tracker enabled.; Issue tracker
Get a defined version for issues: Returns the specified issue tracker version object.; Issue tracker
List repositories watchers: Returns a paginated list of all the watchers on the specified repository.; Repositories
Get a repository application property: Retrieve an [application property](/cloud/bitbucket/application-properties/) value stored against a repository.; properties
Get cache content URI: Retrieve the URI of the content of the specified cache.; Pipelines
List caches: Retrieve the repository pipelines caches.; Pipelines
Get configuration: Retrieve the repository pipelines configuration.; Pipelines
Get a known host: Retrieve a repository level known host.; Pipelines
List known hosts: Find repository level known hosts.; Pipelines
Get a schedule: Retrieve a schedule by its UUID.; Pipelines
List executions of a schedule: Retrieve the executions of a given schedule.; Pipelines
List schedules: Retrieve the configured schedules for the given repository.; Pipelines
Get SSH key pair: 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.; Pipelines
Get a variable for a repository: Retrieve a repository level variable.; Pipelines
List variables for a repository: Find repository level variables.; Pipelines
Get repository runner: Retrieve repository runner by uuid.; Pipelines
Get repository runners: Retrieve repository runners.; Pipelines
List snippets: **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.; Snippets
List snippets in a workspace: Identical to [`/snippets`](/cloud/bitbucket/rest/api-group-snippets/#api-snippets-get), except that the result is further filtered by the snippet owner and only those that are owned by `{workspace}` are returned.; Snippets
Get a snippet: Retrieves a single snippet. Snippets support multiple content types: * application/json * multipart/related * multipart/form-data application/json ---------------- The default content type of the response is `application/json`. Since JSON is always `utf-8`, it cannot reliably contain file contents for files that are not text. Therefore, JSON snippet documents only contain the filename and links to the file contents. This means that in order to retrieve all parts of a snippet, N+1 requests need to be made (where N is the number of files in the snippet). multipart/related ----------------- To retrieve an entire snippet in a single response, use the `Accept: multipart/related` HTTP request header. $ curl -H "Accept: multipart/related" https://api.bitbucket.org/2.0/snippets/evzijst/1 Response: HTTP/1.1 200 OK Content-Length: 2214 Content-Type: multipart/related; start="snippet"; boundary="===============1438169132528273974==" MIME-Version: 1.0 --===============1438169132528273974== Content-Type: application/json; charset="utf-8" MIME-Version: 1.0 Content-ID: snippet { "links": { "self": { "href": "https://api.bitbucket.org/2.0/snippets/evzijst/kypj" }, "html": { "href": "https://bitbucket.org/snippets/evzijst/kypj" }, "comments": { "href": "https://api.bitbucket.org/2.0/snippets/evzijst/kypj/comments" }, "watchers": { "href": "https://api.bitbucket.org/2.0/snippets/evzijst/kypj/watchers" }, "commits": { "href": "https://api.bitbucket.org/2.0/snippets/evzijst/kypj/commits" } }, "id": kypj, "title": "My snippet", "created_on": "2014-12-29T22:22:04.790331+00:00", "updated_on": "2014-12-29T22:22:04.790331+00:00", "is_private": false, "files": { "foo.txt": { "links": { "self": { "href": "https://api.bitbucket.org/2.0/snippets/evzijst/kypj/files/367ab19/foo.txt" }, "html": { "href": "https://bitbucket.org/snippets/evzijst/kypj#file-foo.txt" } } }, "image.png": { "links": { "self": { "href": "https://api.bitbucket.org/2.0/snippets/evzijst/kypj/files/367ab19/image.png" }, "html": { "href": "https://bitbucket.org/snippets/evzijst/kypj#file-image.png" } } } ], "owner": { "username": "evzijst", "nickname": "evzijst", "display_name": "Erik van Zijst", "uuid": "{d301aafa-d676-4ee0-88be-962be7417567}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/evzijst" }, "html": { "href": "https://bitbucket.org/evzijst" }, "avatar": { "href": "https://bitbucket-staging-assetroot.s3.amazonaws.com/c/photos/2013/Jul/31/erik-avatar-725122544-0_avatar.png" } } }, "creator": { "username": "evzijst", "nickname": "evzijst", "display_name": "Erik van Zijst", "uuid": "{d301aafa-d676-4ee0-88be-962be7417567}", "links": { "self": { "href": "https://api.bitbucket.org/2.0/users/evzijst" }, "html": { "href": "https://bitbucket.org/evzijst" }, "avatar": { "href": "https://bitbucket-staging-assetroot.s3.amazonaws.com/c/photos/2013/Jul/31/erik-avatar-725122544-0_avatar.png" } } } } --===============1438169132528273974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-ID: "foo.txt" Content-Disposition: attachment; filename="foo.txt" foo --===============1438169132528273974== Content-Type: image/png MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-ID: "image.png" Content-Disposition: attachment; filename="image.png" iVBORw0KGgoAAAANSUhEUgAAABQAAAAoCAYAAAD+MdrbAAABD0lEQVR4Ae3VMUoDQRTG8ccUaW2m TKONFxArJYJamCvkCnZTaa+VnQdJSBFl2SMsLFrEWNjZBZs0JgiL/+KrhhVmJRbCLPx4O+/DT2TB cbblJxf+UWFVVRNsEGAtgvJxnLm2H+A5RQ93uIl+3632PZyl/skjfOn9Gvdwmlcw5aPUwimG+NT5 EnNN036IaZePUuIcK533NVfal7/5yjWeot2z9ta1cAczHEf7I+3J0ws9Cgx0fsOFpmlfwKcWPuBQ 73Oc4FHzBaZ8llq4q1mr5B2mOUCt815qYR8eB1hG2VJ7j35q4RofaH7IG+Xrf/PfJhfmwtfFYoIN AqxFUD6OMxcvkO+UfKfkOyXfKdsv/AYCHMLVkHAFWgAAAABJRU5ErkJggg== --===============1438169132528273974==-- multipart/form-data ------------------- As with creating new snippets, `multipart/form-data` can be used as an alternative to `multipart/related`. However, the inherently flat structure of form-data means that only basic, root-level properties can be returned, while nested elements like `links` are omitted: $ curl -H "Accept: multipart/form-data" https://api.bitbucket.org/2.0/snippets/evzijst/kypj Response: HTTP/1.1 200 OK Content-Length: 951 Content-Type: multipart/form-data; boundary=----------------------------63a4b224c59f ------------------------------63a4b224c59f Content-Disposition: form-data; name="title" Content-Type: text/plain; charset="utf-8" My snippet ------------------------------63a4b224c59f-- Content-Disposition: attachment; name="file"; filename="foo.txt" Content-Type: text/plain foo ------------------------------63a4b224c59f Content-Disposition: attachment; name="file"; filename="image.png" Content-Transfer-Encoding: base64 Content-Type: application/octet-stream iVBORw0KGgoAAAANSUhEUgAAABQAAAAoCAYAAAD+MdrbAAABD0lEQVR4Ae3VMUoDQRTG8ccUaW2m TKONFxArJYJamCvkCnZTaa+VnQdJSBFl2SMsLFrEWNjZBZs0JgiL/+KrhhVmJRbCLPx4O+/DT2TB cbblJxf+UWFVVRNsEGAtgvJxnLm2H+A5RQ93uIl+3632PZyl/skjfOn9Gvdwmlcw5aPUwimG+NT5 EnNN036IaZePUuIcK533NVfal7/5yjWeot2z9ta1cAczHEf7I+3J0ws9Cgx0fsOFpmlfwKcWPuBQ 73Oc4FHzBaZ8llq4q1mr5B2mOUCt815qYR8eB1hG2VJ7j35q4RofaH7IG+Xrf/PfJhfmwtfFYoIN AqxFUD6OMxcvkO+UfKfkOyXfKdsv/AYCHMLVkHAFWgAAAABJRU5ErkJggg== ------------------------------5957323a6b76--; Snippets
List comments on a snippet: Used to retrieve a paginated list of all comments for a specific snippet. This resource works identical to commit and pull request comments. The default sorting is oldest to newest and can be overridden with the `sort` query parameter.; Snippets
Get a comment on a snippet: Returns the specific snippet comment.; Snippets
List snippet changes: Returns the changes (commits) made on this snippet.; Snippets
Get a previous snippet change: Returns the changes made on this snippet in this commit.; Snippets
Get a snippet's raw file at HEAD: Convenience resource for getting to a snippet's raw files without the need for first having to retrieve the snippet itself and having to pull out the versioned file links.; Snippets
Get a previous revision of a snippet: Identical to `GET /snippets/encoded_id`, except that this endpoint can be used to retrieve the contents of the snippet as it was at an older revision, while `/snippets/encoded_id` always returns the snippet's current revision. Note that only the snippet's file contents are versioned, not its meta data properties like the title. Other than that, the two endpoints are identical in behavior.; Snippets
Get a snippet's raw file: Retrieves the raw contents of a specific file in the snippet. The `Content-Disposition` header will be "attachment" to avoid issues with malevolent executable files. The file's mime type is derived from its filename and returned in the `Content-Type` header. Note that for text files, no character encoding is included as part of the content type.; Snippets
Get snippet changes between versions: Returns the diff of the specified commit against its first parent. Note that this resource is different in functionality from the `patch` resource. The differences between a diff and a patch are: * patches have a commit header with the username, message, etc * diffs support the optional `path=foo/bar.py` query param to filter the diff to just that one file diff (not supported for patches) * for a merge, the diff will show the diff between the merge commit and its first parent (identical to how PRs work), while patch returns a response containing separate patches for each commit on the second parent's ancestry, up to the oldest common ancestor (identical to its reachability). Note that the character encoding of the contents of the diff is unspecified as Git does not track this, making it hard for Bitbucket to reliably determine this.; Snippets
Get snippet patch between versions: Returns the patch of the specified commit against its first parent. Note that this resource is different in functionality from the `diff` resource. The differences between a diff and a patch are: * patches have a commit header with the username, message, etc * diffs support the optional `path=foo/bar.py` query param to filter the diff to just that one file diff (not supported for patches) * for a merge, the diff will show the diff between the merge commit and its first parent (identical to how PRs work), while patch returns a response containing separate patches for each commit on the second parent's ancestry, up to the oldest common ancestor (identical to its reachability). Note that the character encoding of the contents of the patch is unspecified as Git does not track this, making it hard for Bitbucket to reliably determine this.; Snippets
Check if the current user is watching a snippet: Used to check if the current user is watching a specific snippet. Returns 204 (No Content) if the user is watching the snippet and 404 if not. Hitting this endpoint anonymously always returns a 404.; Snippets
List users watching a snippet: Returns a paginated list of all users watching a specific snippet.; Snippets
Get current user: Returns the currently logged in user.; Users
List email addresses for current user: Returns all the authenticated user's email addresses. Both confirmed and unconfirmed.; Users
Get an email address for current user: Returns details about a specific one of the authenticated user's email addresses. Details describe whether the address has been confirmed by the user and whether it is the user's primary address or not.; Users
List repository permissions for a user: **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`.; Repositories
List workspaces for the current user: **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`.; Workspaces
List workspaces for the current user: 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).; Workspaces
Get user permission on a workspace: 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`; Workspaces
List repository permissions in a workspace for a user: 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`.; Repositories
Get a user: Gets the public information associated with a user account. If the user's profile is private, `location`, `website` and `created_on` elements are omitted. Note that the user object returned by this operation is changing significantly, due to privacy changes. See the [announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-changes-gdpr/#changes-to-bitbucket-user-objects) for details.; Users
List GPG keys: 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.; GPG
Get a GPG key: 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.; GPG
List SSH keys: Returns a paginated list of the user's SSH public keys.; SSH
Get a SSH key: Returns a specific SSH public key belonging to a user.; SSH
Get workspace runner: Get workspace runner by uuid.; Pipelines
Get workspace runners: Retrieve workspace runners.; Pipelines
List workspaces for user: **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/).**; Workspaces
Get a workspace: Returns the requested workspace.; Workspaces
List webhooks for a workspace: Returns a paginated list of webhooks installed on this workspace.; WorkspacesWebhooks
Get a webhook for a workspace: Returns the webhook with the specified id installed on the given workspace.; WorkspacesWebhooks
List users in a 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.; Workspaces
Get user membership for a workspace: Returns the workspace membership, which includes a `User` object for the member and a `Workspace` object for the requested workspace.; Workspaces
List user permissions in a workspace: Returns the list of members in a workspace and their permission levels. Permission can be: * `owner` * `collaborator` * `member` **The `collaborator` role is being removed from the Bitbucket Cloud API. For more information, see the [deprecation announcement](/cloud/bitbucket/deprecation-notice-collaborator-role/).** **When you move your administration from Bitbucket Cloud to admin.atlassian.com, the following fields on `workspace_membership` will no longer be present: `last_accessed` and `added_on`. See the [deprecation announcement](/cloud/bitbucket/announcement-breaking-change-workspace-membership/).** Results may be further [filtered](/cloud/bitbucket/rest/intro/#filtering) by permission by adding the following query string parameters: * `q=permission="owner"`; Workspaces
List all repository permissions for a workspace: Returns an object for each repository permission for all of a workspace's repositories. Permissions returned are effective permissions: the highest level of permission the user has. This does not distinguish between direct and indirect (group) privileges. Only users with admin permission for the team may access this resource. Permissions can be: * `admin` * `write` * `read` Results may be further [filtered or sorted](/cloud/bitbucket/rest/intro/#filtering) by repository, user, or permission by adding the following query string parameters: * `q=repository.name="geordi"` or `q=permission>"read"` * `sort=user.display_name` Note that the query parameter values need to be URL escaped so that `=` would become `%3D`.; Workspaces
List a repository permissions for a workspace: Returns an object for the repository permission of each user in the requested repository. Permissions returned are effective permissions: the highest level of permission the user has. This does not distinguish between direct and indirect (group) privileges. Only users with admin permission for the repository may access this resource. Permissions can be: * `admin` * `write` * `read` Results may be further [filtered or sorted](/cloud/bitbucket/rest/intro/#filtering) by user, or permission by adding the following query string parameters: * `q=permission>"read"` * `sort=user.display_name` Note that the query parameter values need to be URL escaped so that `=` would become `%3D`.; Workspaces
List projects in a workspace: Returns the list of projects in this workspace.; Workspaces
Get a project for a workspace: Returns the requested project.; ProjectsWorkspaces
Get the branching model for a project: Return the branching model set at the project level. This view is read-only. The branching model settings can be changed using the [settings](#api-workspaces-workspace-projects-project-key-branching-model-settings-get) API. The returned object: 1. Always has a `development` property. `development.name` is the user-specified branch that can be inherited by an individual repository's branching model. 2. Might have a `production` property. `production` will not be present when `production` is disabled. `production.name` is the user-specified branch that can be inherited by an individual repository's branching model. 3. Always has a `branch_types` array which contains all enabled branch types.; Branching model
Get the branching model config for a project: Return the branching model configuration for a project. The returned object: 1. Always has a `development` property for the development branch. 2. Always a `production` property for the production branch. The production branch can be disabled. 3. The `branch_types` contains all the branch types. 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.; Branching model
List the default reviewers in a project: Return a list of all default reviewers for a project. This is a list of users that will be added as default reviewers to pull requests for any repository within the project.; Projects
Get a default reviewer: Returns the specified default reviewer.; Projects
List project deploy keys: Returns all deploy keys belonging to a project.; Deployments
Get a project deploy key: Returns the deploy key belonging to a specific key ID.; Deployments
List explicit group permissions for a project: Returns a paginated list of explicit group permissions for the given project. This endpoint does not support BBQL features.; Projects
Get an explicit group permission for a project: Returns the group permission for a given group and project. Only users with admin permission for the project may access this resource. Permissions can be: * `admin` * `create-repo` * `write` * `read` * `none`; Projects
List explicit user permissions for a project: Returns a paginated list of explicit user permissions for the given project. This endpoint does not support BBQL features.; Projects
Get an explicit user permission for a project: Returns the explicit user permission for a given user and project. Only users with admin permission for the project may access this resource. Permissions can be: * `admin` * `create-repo` * `write` * `read` * `none`; Projects
List workspace pull requests for a user: 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.; WorkspacesPullrequests
Get the workspace system GPG public key(s): 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.; Workspaces
Create a repository: Creates a new repository. Note: In order to set the project for the newly created repository, pass in either the project key or the project UUID as part of the request body as shown in the examples below: ``` $ 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.; Repositories
Create a branch restriction rule: Creates a new branch restriction rule for a repository. `kind` describes what will be restricted. Allowed values include: `push`, `force`, `delete`, `restrict_merges`, `require_tasks_to_be_completed`, `require_approvals_to_merge`, `require_default_reviewer_approvals_to_merge`, `require_no_changes_requested`, `require_passing_builds_to_merge`, `require_commits_behind`, `reset_pullrequest_approvals_on_change`, `smart_reset_pullrequest_approvals`, `reset_pullrequest_changes_requested_on_change`, `require_all_dependencies_merged`, `enforce_merge_checks`, and `allow_auto_merge_when_builds_pass`. Different kinds of branch restrictions have different requirements: * `push` and `restrict_merges` require `users` and `groups` to be specified. Empty lists are allowed, in which case permission is denied for everybody. The restriction applies to all branches that match. There are two ways to match a branch. It is configured in `branch_match_kind`: 1. `glob`: Matches a branch against the `pattern`. A `'*'` in `pattern` will expand to match zero or more characters, and every other character matches itself. For example, `'foo*'` will match `'foo'` and `'foobar'`, but not `'barfoo'`. `'*'` will match all branches. 2. `branching_model`: Matches a branch against the repository's branching model. The `branch_type` controls the type of branch to match. Allowed values include: `production`, `development`, `bugfix`, `release`, `feature` and `hotfix`. The combination of `kind` and match must be unique. This means that two `glob` restrictions in a repository cannot have the same `kind` and `pattern`. Additionally, two `branching_model` restrictions in a repository cannot have the same `kind` and `branch_type`. `users` and `groups` are lists of users and groups that are except from the restriction. They can only be configured in `push` and `restrict_merges` restrictions. The `push` restriction stops a user pushing to matching branches unless that user is in `users` or is a member of a group in `groups`. The `restrict_merges` stops a user merging pull requests to matching branches unless that user is in `users` or is a member of a group in `groups`. Adding new users or groups to an existing restriction should be done via `PUT`. Note that branch restrictions with overlapping matchers is allowed, but the resulting behavior may be surprising.; Branch restrictions
Approve a commit: Approve the specified commit as the authenticated user. This operation is only available to users that have explicit access to the repository. In contrast, just the fact that a repository is publicly accessible to users does not give them the ability to approve commits.; Commits
Create comment for a commit: Creates new comment on the specified commit. To post a reply to an existing comment, include the `parent.id` field: ``` $ 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}}' ```; Commits
Create a build status for a commit: Creates a new build status against the specified commit. If the specified key already exists, the existing status object will be overwritten. 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" }' ```; Commit statuses
List commits with include/exclude: Identical to `GET /repositories/{workspace}/{repo_slug}/commits`, except that POST allows clients to place the include and exclude parameters in the request body to avoid URL length issues. **Note that this resource does NOT support new commit creation.**; Commits
List commits for revision using include/exclude: Identical to `GET /repositories/{workspace}/{repo_slug}/commits/{revision}`, except that POST allows clients to place the include and exclude parameters in the request body to avoid URL length issues. **Note that this resource does NOT support new commit creation.**; Commits
Add a repository deploy key: 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" }' ```; Deployments
Upload a download artifact: Upload new download artifacts. To upload files, perform a `multipart/form-data` POST containing one or more `files` fields: $ echo Hello World > hello.txt $ curl -s -u evzijst -X POST https://api.bitbucket.org/2.0/repositories/evzijst/git-tests/downloads -F files=@hello.txt When a file is uploaded with the same name as an existing artifact, then the existing file will be replaced.; Downloads
Fork a repository: Creates a new fork of the specified repository. #### Forking a repository To create a fork, specify the workspace explicitly as part of the request body: ``` $ 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; Repositories
Create a webhook for a repository: 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.; RepositoriesWebhooks
Create an issue: Creates a new issue. This call requires authentication. Private repositories or private issue trackers require the caller to authenticate with an account that has appropriate authorization. The authenticated user is used for the issue's `reporter` field.; Issue tracker
Export issues: 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."; Issue tracker
Import issues: A POST request to this endpoint will import the zip file given by the archive parameter into the repository. All existing issues will be deleted and replaced by the contents of the imported zip file. Imports are done through a multipart/form-data POST. There is one valid and required form field, with the name "archive," which needs to be a file field: ``` $ curl -u <username> -X POST -F archive=@/path/to/file.zip https://api.bitbucket.org/2.0/repositories/<owner_username>/<repo_slug>/issues/import ```; Issue tracker
Upload an attachment to an issue: Upload new issue attachments. To upload files, perform a `multipart/form-data` POST containing one or more file fields. When a file is uploaded with the same name as an existing attachment, then the existing file will be replaced.; Issue tracker
Modify the state of an issue: Makes a change to the specified issue. For example, to change an issue's state and assignee, create a new change object that modifies these fields: ``` 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.; Issue tracker
Create a comment on an issue: 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."}}' ```; Issue tracker
Create a pull request: Creates a new pull request where the destination repository is this repository and the author is the authenticated user. The minimum required fields to create a pull request are `title` and `source`, specified by a branch name. ``` 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; Pullrequests
Approve a pull request: Approve the specified pull request as the authenticated user.; Pullrequests
Create a comment on a pull request: Creates a new pull request comment. Returns the newly created pull request comment.; Pullrequests
Resolve a comment thread: Resolve a comment thread; Pullrequests
Decline a pull request: Declines the pull request.; Pullrequests
Merge a pull request: Merges the pull request.; Pullrequests
Request changes for a pull request: Request changes for a pull request; Pullrequests
Create a task on 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.; Pullrequests
Create a branch: Creates a new branch in the specified repository. The payload of the POST should consist of a JSON document that contains the name of the tag and the target hash. ``` 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.; Refs
Create a tag: 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.; Refs
Create a commit by uploading a file: This endpoint is used to create new commits in the repository by uploading files. To add a new file to a repository: ``` $ 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.; SourceRepositories
Create a snippet: Creates a new snippet under the authenticated user's account. Snippets can contain multiple files. Both text and binary files are supported. The simplest way to create a new snippet from a local file: $ curl -u username:password -X POST https://api.bitbucket.org/2.0/snippets -F file=@image.png Creating snippets through curl has a few limitations and so let's look at a more complicated scenario. Snippets are created with a multipart POST. Both `multipart/form-data` and `multipart/related` are supported. Both allow the creation of snippets with both meta data (title, etc), as well as multiple text and binary files. The main difference is that `multipart/related` can use rich encoding for the meta data (currently JSON). multipart/related (RFC-2387) ---------------------------- This is the most advanced and efficient way to create a paste. POST /2.0/snippets/evzijst HTTP/1.1 Content-Length: 1188 Content-Type: multipart/related; start="snippet"; boundary="===============1438169132528273974==" MIME-Version: 1.0 --===============1438169132528273974== Content-Type: application/json; charset="utf-8" MIME-Version: 1.0 Content-ID: snippet { "title": "My snippet", "is_private": true, "scm": "git", "files": { "foo.txt": {}, "image.png": {} } } --===============1438169132528273974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-ID: "foo.txt" Content-Disposition: attachment; filename="foo.txt" foo --===============1438169132528273974== Content-Type: image/png MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-ID: "image.png" Content-Disposition: attachment; filename="image.png" iVBORw0KGgoAAAANSUhEUgAAABQAAAAoCAYAAAD+MdrbAAABD0lEQVR4Ae3VMUoDQRTG8ccUaW2m TKONFxArJYJamCvkCnZTaa+VnQdJSBFl2SMsLFrEWNjZBZs0JgiL/+KrhhVmJRbCLPx4O+/DT2TB cbblJxf+UWFVVRNsEGAtgvJxnLm2H+A5RQ93uIl+3632PZyl/skjfOn9Gvdwmlcw5aPUwimG+NT5 EnNN036IaZePUuIcK533NVfal7/5yjWeot2z9ta1cAczHEf7I+3J0ws9Cgx0fsOFpmlfwKcWPuBQ 73Oc4FHzBaZ8llq4q1mr5B2mOUCt815qYR8eB1hG2VJ7j35q4RofaH7IG+Xrf/PfJhfmwtfFYoIN AqxFUD6OMxcvkO+UfKfkOyXfKdsv/AYCHMLVkHAFWgAAAABJRU5ErkJggg== --===============1438169132528273974==-- The request contains multiple parts and is structured as follows. The first part is the JSON document that describes the snippet's properties or meta data. It either has to be the first part, or the request's `Content-Type` header must contain the `start` parameter to point to it. The remaining parts are the files of which there can be zero or more. Each file part should contain the `Content-ID` MIME header through which the JSON meta data's `files` element addresses it. The value should be the name of the file. `Content-Disposition` is an optional MIME header. The header's optional `filename` parameter can be used to specify the file name that Bitbucket should use when writing the file to disk. When present, `filename` takes precedence over the value of `Content-ID`. When the JSON body omits the `files` element, the remaining parts are not ignored. Instead, each file is added to the new snippet as if its name was explicitly linked (the use of the `files` elements is mandatory for some operations like deleting or renaming files). multipart/form-data ------------------- The use of JSON for the snippet's meta data is optional. Meta data can also be supplied as regular form fields in a more conventional `multipart/form-data` request: $ curl -X POST -u credentials https://api.bitbucket.org/2.0/snippets -F title="My snippet" -F file=@foo.txt -F file=@image.png POST /2.0/snippets HTTP/1.1 Content-Length: 951 Content-Type: multipart/form-data; boundary=----------------------------63a4b224c59f ------------------------------63a4b224c59f Content-Disposition: form-data; name="file"; filename="foo.txt" Content-Type: text/plain foo ------------------------------63a4b224c59f Content-Disposition: form-data; name="file"; filename="image.png" Content-Type: application/octet-stream ?PNG IHDR?1??I..... ------------------------------63a4b224c59f Content-Disposition: form-data; name="title" My snippet ------------------------------63a4b224c59f-- Here the meta data properties are included as flat, top-level form fields. The file attachments use the `file` field name. To attach multiple files, simply repeat the field. The advantage of `multipart/form-data` over `multipart/related` is that it can be easier to build clients. Essentially all properties are optional, `title` and `files` included. Sharing and Visibility ---------------------- Snippets can be either public (visible to anyone on Bitbucket, as well as anonymous users), or private (visible only to members of the workspace). This is controlled through the snippet's `is_private` element: * **is_private=false** -- everyone, including anonymous users can view the snippet * **is_private=true** -- only workspace members can view the snippet To create the snippet under a workspace, just append the workspace ID to the URL. See [`/2.0/snippets/{workspace}`](/cloud/bitbucket/rest/api-group-snippets/#api-snippets-workspace-post).; Snippets
Create a snippet for a workspace: Identical to [`/snippets`](/cloud/bitbucket/rest/api-group-snippets/#api-snippets-post), except that the new snippet will be created under the workspace specified in the path parameter `{workspace}`.; Snippets
Create a comment on a snippet: Creates a new comment. The only required field in the body is `content.raw`. To create a threaded reply to an existing comment, include `parent.id`.; Snippets
Add a new GPG key: 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 ```; GPG
Add a new SSH key: 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 ```; SSH
Create a webhook for a workspace: Creates a new webhook on the specified workspace. Workspace webhooks are fired for events from all repositories contained by that workspace. 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.; WorkspacesWebhooks
Create a project in a workspace: Creates a new project. Note that the avatar has to be embedded as either a data-url or a URL to an external image as shown in the examples below: ``` $ 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 } ```; Projects
Create a project deploy key: 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" }' ```; Deployments
Update an installed app: 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.; Addon
Update a repository: Since this endpoint can be used to both update and to create a repository, the request body depends on the intent. #### Creation See the POST documentation for the repository endpoint for an example of the request body. #### Update Note: Changing the `name` of the repository will cause the location to be changed. This is because the URL of the repo is derived from the name (a process called slugification). In such a scenario, it is possible for the request to fail if the newly created slug conflicts with an existing repository's slug. But if there is no conflict, the new location will be returned in the `Location` header of the response.; Repositories
Update a branch restriction rule: Updates an existing branch restriction rule. Fields not present in the request body are ignored. See [`POST`](/cloud/bitbucket/rest/api-group-branch-restrictions/#api-repositories-workspace-repo-slug-branch-restrictions-post) for details.; Branch restrictions
Update the branching model config for a repository: Update the branching model configuration for a repository. The `development` branch can be configured to a specific branch or to track the main branch. When set to a specific branch it must currently exist. Only the passed properties will be updated. The properties not passed will be left unchanged. A request without a `development` property will leave the development branch unchanged. It is possible for the `development` branch to be invalid. This happens when it points at a specific branch that has been deleted. This is indicated in the `is_valid` field for the branch. It is not possible to update the settings for `development` if that would leave the branch in an invalid state. Such a request will be rejected. The `production` branch can be a specific branch, the main branch or disabled. When set to a specific branch it must currently exist. The `enabled` property can be used to enable (`true`) or disable (`false`) it. Only the passed properties will be updated. The properties not passed will be left unchanged. A request without a `production` property will leave the production branch unchanged. It is possible for the `production` branch to be invalid. This happens when it points at a specific branch that has been deleted. This is indicated in the `is_valid` field for the branch. A request that would leave `production` enabled and invalid will be rejected. It is possible to update `production` and make it invalid if it would also be left disabled. The `branch_types` property contains the branch types to be updated. Only the branch types passed will be updated. All updates will be rejected if it would leave the branching model in an invalid state. For branch types this means that: 1. The prefixes for all enabled branch types are valid. For example, it is not possible to use '*' inside a Git prefix. 2. A prefix of an enabled branch type must not be a prefix of another enabled branch type. This is to ensure that a branch can be easily classified by its prefix unambiguously. It is possible to store an invalid prefix if that branch type would be left disabled. Only the passed properties will be updated. The properties not passed will be left unchanged. Each branch type must have a `kind` property to identify it. 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.; Branching model
Update a commit comment: 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!"}' ```; Commits
Update a build status for a commit: Used to update the current status of a build status object on the specific commit. This operation can also be used to change other properties of the build status: * `state` * `name` * `description` * `url` * `refname` The `key` cannot be changed.; Commit statuses
Add a user to the default reviewers: Adds the specified user to the repository's list of default reviewers. This method is idempotent. Adding a user a second time has no effect.; Pullrequests
Update a repository deploy key: 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", }' ```; Deployments
Update a webhook for a repository: 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.; RepositoriesWebhooks
Update an issue: 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.; Issue tracker
Update a comment on an issue: 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."}' ```; Issue tracker
Vote for an issue: Vote for this issue. To cast your vote, do an empty PUT. The 204 status code indicates that the operation was successful.; Issue tracker
Watch an issue: Start watching this issue. To start watching this issue, do an empty PUT. The 204 status code indicates that the operation was successful.; Issue tracker
Set the inheritance state for repository settings: Set the inheritance state for repository settings; Repositories
Update an explicit group permission for a repository: Updates the group permission, or grants a new permission if one does not already exist. Only users with admin permission for the repository may access this resource. The only authentication method supported for this endpoint is via app passwords. Permissions can be: * `admin` * `write` * `read`; Repositories
Update an explicit user permission for a repository: Updates the explicit user permission for a given user and repository. The selected user must be a member of the workspace, and cannot be the workspace owner. Only users with admin permission for the repository may access this resource. The only authentication method for this endpoint is via app passwords. Permissions can be: * `admin` * `write` * `read`; Repositories
Update a pull request: Mutates the specified pull request. This can be used to change the pull request's branches or description. Only open pull requests can be mutated.; Pullrequests
Update a comment on a pull request: Updates a specific pull request comment.; Pullrequests
Update a task on a pull request: Updates a specific pull request task.; Pullrequests
Update a snippet: Used to update a snippet. Use this to add and delete files and to change a snippet's title. To update a snippet, one can either PUT a full snapshot, or only the parts that need to be changed. The contract for PUT on this API is that properties missing from the request remain untouched so that snippets can be efficiently manipulated with differential payloads. To delete a property (e.g. the title, or a file), include its name in the request, but omit its value (use `null`). As in Git, explicit renaming of files is not supported. Instead, to rename a file, delete it and add it again under another name. This can be done atomically in a single request. Rename detection is left to the SCM. PUT supports three different content types for both request and response bodies: * `application/json` * `multipart/related` * `multipart/form-data` The content type used for the request body can be different than that used for the response. Content types are specified using standard HTTP headers. Use the `Content-Type` and `Accept` headers to select the desired request and response format. application/json ---------------- As with creation and retrieval, the content type determines what properties can be manipulated. `application/json` does not support file contents and is therefore limited to a snippet's meta data. To update the title, without changing any of its files: $ curl -X POST -H "Content-Type: application/json" https://api.bitbucket.org/2.0/snippets/evzijst/kypj -d '{"title": "Updated title"}' To delete the title: $ curl -X POST -H "Content-Type: application/json" https://api.bitbucket.org/2.0/snippets/evzijst/kypj -d '{"title": null}' Not all parts of a snippet can be manipulated. The owner and creator for instance are immutable. multipart/related ----------------- `multipart/related` can be used to manipulate all of a snippet's properties. The body is identical to a POST. properties omitted from the request are left unchanged. Since the `start` part contains JSON, the mechanism for manipulating the snippet's meta data is identical to `application/json` requests. To update one of a snippet's file contents, while also changing its title: PUT /2.0/snippets/evzijst/kypj HTTP/1.1 Content-Length: 288 Content-Type: multipart/related; start="snippet"; boundary="===============1438169132528273974==" MIME-Version: 1.0 --===============1438169132528273974== Content-Type: application/json; charset="utf-8" MIME-Version: 1.0 Content-ID: snippet { "title": "My updated snippet", "files": { "foo.txt": {} } } --===============1438169132528273974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-ID: "foo.txt" Content-Disposition: attachment; filename="foo.txt" Updated file contents. --===============1438169132528273974==-- Here only the parts that are changed are included in the body. The other files remain untouched. Note the use of the `files` list in the JSON part. This list contains the files that are being manipulated. This list should have corresponding multiparts in the request that contain the new contents of these files. If a filename in the `files` list does not have a corresponding part, it will be deleted from the snippet, as shown below: PUT /2.0/snippets/evzijst/kypj HTTP/1.1 Content-Length: 188 Content-Type: multipart/related; start="snippet"; boundary="===============1438169132528273974==" MIME-Version: 1.0 --===============1438169132528273974== Content-Type: application/json; charset="utf-8" MIME-Version: 1.0 Content-ID: snippet { "files": { "image.png": {} } } --===============1438169132528273974==-- To simulate a rename, delete a file and add the same file under another name: PUT /2.0/snippets/evzijst/kypj HTTP/1.1 Content-Length: 212 Content-Type: multipart/related; start="snippet"; boundary="===============1438169132528273974==" MIME-Version: 1.0 --===============1438169132528273974== Content-Type: application/json; charset="utf-8" MIME-Version: 1.0 Content-ID: snippet { "files": { "foo.txt": {}, "bar.txt": {} } } --===============1438169132528273974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-ID: "bar.txt" Content-Disposition: attachment; filename="bar.txt" foo --===============1438169132528273974==-- multipart/form-data ----------------- Again, one can also use `multipart/form-data` to manipulate file contents and meta data atomically. $ curl -X PUT http://localhost:12345/2.0/snippets/evzijst/kypj -F title="My updated snippet" -F file=@foo.txt PUT /2.0/snippets/evzijst/kypj HTTP/1.1 Content-Length: 351 Content-Type: multipart/form-data; boundary=----------------------------63a4b224c59f ------------------------------63a4b224c59f Content-Disposition: form-data; name="file"; filename="foo.txt" Content-Type: text/plain foo ------------------------------63a4b224c59f Content-Disposition: form-data; name="title" My updated snippet ------------------------------63a4b224c59f To delete a file, omit its contents while including its name in the `files` field: $ curl -X PUT https://api.bitbucket.org/2.0/snippets/evzijst/kypj -F files=image.png PUT /2.0/snippets/evzijst/kypj HTTP/1.1 Content-Length: 149 Content-Type: multipart/form-data; boundary=----------------------------ef8871065a86 ------------------------------ef8871065a86 Content-Disposition: form-data; name="files" image.png ------------------------------ef8871065a86-- The explicit use of the `files` element in `multipart/related` and `multipart/form-data` is only required when deleting files. The default mode of operation is for file parts to be processed, regardless of whether or not they are listed in `files`, as a convenience to the client.; Snippets
Update a comment on a snippet: Updates a comment. The only required field in the body is `content.raw`. Comments can only be updated by their author.; Snippets
Update a previous revision of a snippet: Identical to `UPDATE /snippets/encoded_id`, except that this endpoint takes an explicit commit revision. Only the snippet's "HEAD"/"tip" (most recent) version can be updated and requests on all other, older revisions fail by returning a 405 status. Usage of this endpoint over the unrestricted `/snippets/encoded_id` could be desired if the caller wants to be sure no concurrent modifications have taken place between the moment of the UPDATE request and the original GET. This can be considered a so-called "Compare And Swap", or CAS operation. Other than that, the two endpoints are identical in behavior.; Snippets
Watch a snippet: Used to start watching a specific snippet. Returns 204 (No Content).; Snippets
Update a SSH key: Updates a specific SSH public key on a user's account Note: Only the 'comment' field can be updated using this API. To modify the key or comment values, you must delete and add the key again. Example: ``` $ curl -X PUT -H "Content-Type: application/json" -d '{"label": "Work key"}' https://api.bitbucket.org/2.0/users/{ed08f5e1-605b-4f4a-aee4-6c97628a673e}/ssh-keys/{b15b6026-9c02-4626-b4ad-b905f99f763a} ```; SSH
Update a webhook for a workspace: 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.; WorkspacesWebhooks
Update a project for a workspace: Since this endpoint can be used to both update and to create a project, the request body depends on the intent. #### Creation See the POST documentation for the project collection for an example of the request body. Note: The `key` should not be specified in the body of request (since it is already present in the URL). The `name` is required, everything else is optional. #### Update See the POST documentation for the project collection for an example of the request body. Note: The key is not required in the body (since it is already in the URL). The key may be specified in the body, if the intent is to change the key itself. In such a scenario, the location of the project is changed and is returned in the `Location` header of the response.; Projects
Update the branching model config for a project: Update the branching model configuration for a project. The `development` branch can be configured to a specific branch or to track the main branch. Any branch name can be supplied, but will only successfully be applied to a repository via inheritance if that branch exists for that repository. Only the passed properties will be updated. The properties not passed will be left unchanged. A request without a `development` property will leave the development branch unchanged. The `production` branch can be a specific branch, the main branch or disabled. Any branch name can be supplied, but will only successfully be applied to a repository via inheritance if that branch exists for that repository. The `enabled` property can be used to enable (`true`) or disable (`false`) it. Only the passed properties will be updated. The properties not passed will be left unchanged. A request without a `production` property will leave the production branch unchanged. The `branch_types` property contains the branch types to be updated. Only the branch types passed will be updated. All updates will be rejected if it would leave the branching model in an invalid state. For branch types this means that: 1. The prefixes for all enabled branch types are valid. For example, it is not possible to use '*' inside a Git prefix. 2. A prefix of an enabled branch type must not be a prefix of another enabled branch type. This is to ensure that a branch can be easily classified by its prefix unambiguously. It is possible to store an invalid prefix if that branch type would be left disabled. Only the passed properties will be updated. The properties not passed will be left unchanged. Each branch type must have a `kind` property to identify it. 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.; Branching model
Add the specific user as a default reviewer for the project: Adds the specified user to the project's list of default reviewers. The method is idempotent. Accepts an optional body containing the `uuid` of the user to be added.; Projects
Update an explicit group permission for a project: Updates the group permission, or grants a new permission if one does not already exist. Only users with admin permission for the project may access this resource. Due to security concerns, the JWT and OAuth authentication methods are unsupported. This is to ensure integrations and add-ons are not allowed to change permissions. Permissions can be: * `admin` * `create-repo` * `write` * `read`; Projects
Update an explicit user permission for a project: Updates the explicit user permission for a given user and project. The selected user must be a member of the workspace, and cannot be the workspace owner. Only users with admin permission for the project may access this resource. Due to security concerns, the JWT and OAuth authentication methods are unsupported. This is to ensure integrations and add-ons are not allowed to change permissions. Permissions can be: * `admin` * `create-repo` * `write` * `read`; Projects
Get a user application property: Retrieve an [application property](/cloud/bitbucket/application-properties/) value stored against a user.; properties
Search for code in a user's repositories: This API will be deprecated on November 1, 2026. Search for code in the repositories of the specified user. Note that searches can match in the file's text (`content_matches`), the path (`path_matches`), or both. You can use the same syntax for the search query as in the UI. E.g. to search for "foo" only within the repository "demo", use the query parameter `search_query=foo+repo:demo`. Similar to other APIs, you can request more fields using a `fields` query parameter. E.g. to get some more information about the repository of matched files, use the query parameter `search_query=foo&fields=%2Bvalues.file.commit.repository` (the `%2B` is a URL-encoded `+`).; Search
Search for code in a team's repositories: This API will be deprecated on November 1, 2026. Search for code in the repositories of the specified team. Note that searches can match in the file's text (`content_matches`), the path (`path_matches`), or both. You can use the same syntax for the search query as in the UI. E.g. to search for "foo" only within the repository "demo", use the query parameter `search_query=foo+repo:demo`. Similar to other APIs, you can request more fields using a `fields` query parameter. E.g. to get some more information about the repository of matched files, use the query parameter `search_query=foo&fields=%2Bvalues.file.commit.repository` (the `%2B` is a URL-encoded `+`). Try `fields=%2Bvalues.*.*.*.*` to get an idea what's possible.; Search
Search for code in a workspace: This API will be deprecated on November 1, 2026. Search for code in the repositories of the specified workspace. Note that searches can match in the file's text (`content_matches`), the path (`path_matches`), or both. You can use the same syntax for the search query as in the UI. E.g. to search for "foo" only within the repository "demo", use the query parameter `search_query=foo+repo:demo`. Similar to other APIs, you can request more fields using a `fields` query parameter. E.g. to get some more information about the repository of matched files, use the query parameter `search_query=foo&fields=%2Bvalues.file.commit.repository` (the `%2B` is a URL-encoded `+`). Try `fields=%2Bvalues.*.*.*.*` to get an idea what's possible.; Search
Stop a pipeline: Signal the stop of a pipeline and all of its steps that not have completed yet.; Pipelines
Update a commit application property: Update an [application property](/cloud/bitbucket/application-properties/) value stored against a commit.; properties
Update a variable for an environment: Update a deployment environment level variable.; Pipelines
Update an environment: Update an environment; Deployments
Update a variable for a team: Update a team level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).; Pipelines
Update a variable for a user: Update a user level variable. This endpoint has been deprecated, and you should use the new workspaces endpoint. For more information, see [the announcement](https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-teams-deprecation/).; Pipelines
Update variable for a workspace: Update a workspace level variable.; Pipelines
Update a pull request application property: Update an [application property](/cloud/bitbucket/application-properties/) value stored against a pull request.; properties
Update the next build number: Update the next build number that should be assigned to a pipeline. The next build number that will be configured has to be strictly higher than the current latest build number for this repository.; Pipelines
Update a repository application property: Update an [application property](/cloud/bitbucket/application-properties/) value stored against a repository.; properties
Update configuration: Update the pipelines configuration for a repository.; Pipelines
Update SSH key pair: Create or update the repository SSH key pair. The private key will be set as a default SSH identity in your build container.; Pipelines
Update a known host: Update a repository level known host.; Pipelines
Update a schedule: Update a schedule.; Pipelines
Update a variable for a repository: Update a repository level variable.; Pipelines
Update repository runner: Update repository runner.; Pipelines
Update a user application property: Update an [application property](/cloud/bitbucket/application-properties/) value stored against a user.; properties
Update workspace runner: Update workspace runner.; Pipelines

FAQ

Bitbucket integration, answered

How do AI agents use Bitbucket through Open Connector?: Your user connects Bitbucket once with one of its cataloged authentication methods. Open Connector stores the credential in an encrypted vault and exposes Bitbucket tools to your agent over MCP or a typed API, with credentials injected server-side on each call.
Is this a Bitbucket MCP server?: Yes. Open Connector can serve Bitbucket as a named MCP server with a scoped allowlist and a per-user connection URL, so any MCP client can call Bitbucket actions with credentials injected server-side.
Where do Bitbucket credentials live?: In your own infrastructure. Open Connector keeps credentials in its own vault and injects them at call time, so they never leave your environment.

Give your agents Bitbucket — keep the keys.

Open source, self-hostable, with Bitbucket credentials that never leave your infrastructure. Run it from source today.

View source on GitHub How the MCP gateway works →