This changelog is the source of truth for all changes to the Bitbucket API and Bitbucket Connect API that affect people using Bitbucket Cloud and developing Bitbucket Cloud apps.
To ask any questions related to Bitbucket Cloud development please visit the Bitbucket Cloud developer community.
Bitbucket Cloud is transitioning to API tokens to enhance security. As part of this transition, app passwords will be fully deprecated on Jul 28, 2026. To help you identify and migrate any remaining usage before the final removal, we are running a series of controlled brownouts starting Jun 9, 2026.
What’s changing:
During each brownout window, API requests authenticated using app passwords will fail with an HTTP 401 while Git-over-HTTPS operations authenticated using app passwords will fail with an HTTP 410.
What you need to do:
You must migrate to API tokens before Jul 28, 2026. API tokens offer improved security, expiration controls, and centralized management.
To create and use an API token:
Select your Profile icon, then select Account settings.
Select Security, then Create and manage API tokens, and then select Create API token.
Select Create API token with scopes.
Name the token, set an expiry date, select Bitbucket as the app.
Assign the necessary scopes and save the token.
Update your integration credentials, CI/CD pipelines, and local Git configurations with the new API token.
For detailed guidance, see the API token documentation.
Dates | Brownout duration per window | Brownout window start times (UTC) |
|---|---|---|
Jun 09, 2026 | 15 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 10, 2026 | 15 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 11, 2026 | 15 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 12, 2026 | 15 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 13, 2026 | 15 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 14, 2026 | 15 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 15, 2026 | 15 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 16, 2026 | 30 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 17, 2026 | 30 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 18, 2026 | 30 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 19, 2026 | 30 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 20, 2026 | 30 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 21, 2026 | 30 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 22, 2026 | 30 minutes | 00:00, 06:00, 12:00, 18:00 |
Jun 23, 2026 | 1 hour | 00:00, 06:00, 12:00, 18:00 |
Jun 24, 2026 | 1 hour | 00:00, 06:00, 12:00, 18:00 |
Jun 25, 2026 | 1 hour | 00:00, 06:00, 12:00, 18:00 |
Jun 26, 2026 | 1 hour | 00:00, 06:00, 12:00, 18:00 |
Jun 27, 2026 | 1 hour | 00:00, 06:00, 12:00, 18:00 |
Jun 28, 2026 | 1 hour | 00:00, 06:00, 12:00, 18:00 |
Jun 29, 2026 | 1 hour | 00:00, 06:00, 12:00, 18:00 |
Jun 30, 2026 | 2 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 01, 2026 | 2 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 02, 2026 | 2 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 03, 2026 | 2 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 04, 2026 | 2 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 05, 2026 | 2 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 06, 2026 | 2 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 07, 2026 | 3 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 08, 2026 | 3 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 09, 2026 | 3 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 10, 2026 | 3 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 11, 2026 | 3 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 12, 2026 | 3 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 13, 2026 | 3 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 14, 2026 | 4 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 15, 2026 | 4 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 16, 2026 | 4 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 17, 2026 | 4 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 18, 2026 | 4 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 19, 2026 | 4 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 20, 2026 | 4 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 21, 2026 | 5 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 22, 2026 | 5 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 23, 2026 | 5 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 24, 2026 | 5 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 25, 2026 | 5 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 26, 2026 | 5 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 27, 2026 | 5 hours | 00:00, 06:00, 12:00, 18:00 |
Jul 28, 2026 | Final removal |
|
As recently announced in Raising the bar on Marketplace cloud app security: together we are updating the Marketplace Security Bug Fix Policy to shorten vulnerability remediation timelines for Marketplace cloud apps. These changes ensure a higher security standard across our ecosystem.
What’s changing
The remediation Service Level Objectives (SLOs) for Marketplace cloud apps are being shortened. The timelines for Data Center apps remain unchanged.
Updated Cloud App SLOs (Enforceable September 1, 2026):
Critical: 10 days
High: 4 weeks
Medium: 12 weeks
Low: 25 weeks
Data Center App SLOs (Unchanged):
Critical: 12 weeks
High: 12 weeks
Medium: 12 weeks
Low: 25 weeks
Additionally, we have published the Marketplace Security Enforcement Policy, a consolidated source of truth for marketplace security compliance expectations, including vulnerability management, OAuth compliance, partner verification, bug bounty participation, and incident response.
What you need to do
Review the new timelines: Ensure your internal processes are updated to meet the new cloud app SLOs by September 1, 2026.
Check your tickets: We have corrected an issue where some AMS Data Center tickets incorrectly showed cloud remediation dates. If you believe a ticket still has an incorrect date, please raise an ECOHELP ticket.
Watch the policy page: The Marketplace Security Enforcement Policy is a living document, we recommend "watching" the page for future updates.
We've introduced the Tile component for Forge UI Kit apps, now available in Preview. The Tile component is a rounded square container for displaying assets like emojis, or objects in a consistent, styled way.
The component supports various sizes (from 16px to 48px), customizable background colors using design tokens, optional borders, and adjustable internal padding for different asset types including third-party logos.
For implementation details and examples, see the Tile component documentation.
SSH access to Bitbucket Cloud repositories via bitbucket.org will be removed after approximately six months. SSH traffic is being separated from HTTPS traffic to enable enhanced security protections on Bitbucket's public web and API endpoints.
Customers who use Git over SSH must update their remote URLs to use ssh.bitbucket.org instead of bitbucket.org. HTTPS access to bitbucket.org is not affected by this change.
What is changing
Bitbucket Cloud is splitting HTTPS and SSH traffic so that bitbucket.org will serve only HTTPS requests. All SSH-based Git operations (clone, push, pull, fetch) must use the new ssh.bitbucket.org hostname.
Migration steps
For each repository using an SSH remote, update the remote URL:
1
git remote set-url origin git@ssh.bitbucket.org:<workspace>/<repo>.gitOn first connection to ssh.bitbucket.org, verify and accept the new host key when prompted, or pre-add it to ~/.ssh/known_hosts.
Update any CI/CD pipelines, deployment scripts, or automation that use SSH to clone or push to bitbucket.org.
If your network restricts outbound SSH connections via firewall rules, ensure ssh.bitbucket.org on port 22 is allowlisted.
More details are captured in this community blogpost.
Timeline
Customers will have approximately six months from the announcement date to complete the migration. After the migration period ends, SSH connections to bitbucket.org will be refused.
To maintain system stability as our usage scales, we updated Bitbucket Pipelines to only detect the [skip ci] or [ci skip] label within the first 200 characters of a commit message. This means pipelines won’t be skipped if the label appears further in a long message.
To ensure your builds are intentionally skipped, place the label near the start of your commit message, ideally in the subject line. Manual runs are not affected by this change.
For details, read
https://support.atlassian.com/bitbucket-cloud/kb/how-to-skip-triggering-an-automatic-pipeline-build-using-skip-ci-label/.
What’s changing
We’ve introduced a new Bitbucket REST API endpoint that allows a Forge app to retrieve the clientKey of its linked Connect app installation.
This endpoint supports the migration process from Connect to Forge. By retrieving the clientKey, the installed Forge app can identify the equivalent Connect app installation, enabling you to perform data migration or cleanup tasks effectively.
What you need to do
To use this endpoint, ensure you have configured the linkage between your Connect and Forge apps.
Add the forgeAppId key to your Connect app descriptor.
Use the new endpoint to fetch the clientKey during your app's migration logic.
See https://developer.atlassian.com/cloud/bitbucket/link-connect-to-its-equivalent-forge-app/ on how to configure your Connect → Forge app linkage.
We are deprecating the Bitbucket Cloud legacy code search API endpoints effective May 1, 2026, with full removal on November 1, 2026.
The following endpoints are being decommissioned and will be removed on November 1, 2026:
GET /2.0/repositories/{workspace}/{repo_slug}/search/code — Repository-level code search
GET /2.0/workspaces/{workspace}/search/code — Workspace-level code search
We are actively working on the new API which will be released ahead of the removal.
As shared in our https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3052, Bitbucket Cloud will fully deprecate / change behaviour for a small set of OAuth2 features on May 4, 2026. To help teams identify and migrate any remaining usage ahead of the enforcement date, we will run a series of controlled brownouts starting Apr 20, 2026, for two weeks, after which the functionality will be fully removed on May 4, 2026.
During each brownout window:
All OAuth authenticated requests directed at www.bitbucket.org will fail with an HTTP 401 error code
All OAuth authenticated requests which provide the OAuth access token in the access_token query parameters / POST body will fail with an HTTP 401 error code
The Client credentials grant flow will not issue refresh tokens in their token response.
OAuth token response payloads will return “scope" instead of “scopes" (See notes)
Notes:
The minting of OAuth2 access tokens should always be made to https://bitbucket.org/site/oauth2/access_token. Bitbucket’s API does not mount these urls under the api subdomain.
In the week beginning Apr 12, 2026 the scope property will be returned alongside the scopes property, allowing time to onboard prior to the start of the brownout.
Dates | Brownout duration per window | Brownout window start times (UTC) |
|---|---|---|
Apr 20, 2026 | 15 minutes | 00:00, 06:00, 12:00, 18:00 |
Apr 21, 2026 | 15 minutes | 00:00, 06:00, 12:00, 18:00 |
Apr 22, 2026 | 30 minutes | 00:00, 06:00, 12:00, 18:00 |
Apr 23, 2026 | 30 minutes | 00:00, 06:00, 12:00, 18:00 |
Apr 24, 2026 | 1 hour | 00:00, 06:00, 12:00, 18:00 |
Apr 25, 2026 | 1 hour | 00:00, 06:00, 12:00, 18:00 |
Apr 26, 2026 | 2 hours | 00:00, 06:00, 12:00, 18:00 |
Apr 27, 2026 | 2 hours | 00:00, 06:00, 12:00, 18:00 |
Apr 28, 2026 | 3 hours | 00:00, 06:00, 12:00, 18:00 |
Apr 29, 2026 | 3 hours | 00:00, 06:00, 12:00, 18:00 |
Apr 30, 2026 | 4 hours | 00:00, 06:00, 12:00, 18:00 |
May 1, 2026 | 4 hours | 00:00, 06:00, 12:00, 18:00 |
May 2, 2026 | 5 hours | 00:00, 06:00, 12:00, 18:00 |
May 3, 2026 | 5 hours | 00:00, 06:00, 12:00, 18:00 |
May 4, 2026 | Final removal |
|
You can now nominate genuine migration blockers or major customer‑impact risks via the “Request review” flow on FRGE issues.
This flow will allow us to triage and assess requests to address remaining blockers to Forge migration before Connect end of support in December 2026. We’ll review requests over 3 monthly cycles, then freeze decisions.
Please review for existing tickets before creating new FRGE tickets. You may also review the announcement.
We’ll publish the outcomes of these decisions on the following pages:
Approved / available capabilities:
https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-forge-equivalences/connect-forge-capabilities-available/
Not‑available capabilities (including rejected requests):
https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-forge-equivalences/connect-forge-capabilities-notavailable/
We've introduced three new Forge triggers for Bitbucket deployment events. These triggers allow your Forge app to respond to deployment lifecycle events in Bitbucket Pipelines.
The new triggers are:
avi:bitbucket:pending:deployment — Fires when a deployment is pending
avi:bitbucket:started:deployment — Fires when a deployment starts
avi:bitbucket:completed:deployment — Fires when a deployment completes
To use these triggers, add them to the trigger section of your app's manifest.yml file. Each trigger provides deployment event data including environment, state, and pipeline details.
For more information, see Bitbucket events.
Following this deprecation announcement on Feb 17, 2026, the Connect Inspector Service is now decommissoned.
We recommend migrating to Atlassian Forge for a more robust Events model, as Atlassian Connect will reach end of support in December 2026.
Developers who still need similar functionality can use the open‑sourced version of the tool.
As shared in our https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-2887, Bitbucket Cloud will fully deprecate support for OAuth 1.0 and implicit grant flows on Feb 27, 2026. To help teams identify and migrate any remaining usage ahead of the enforcement date, we will run a series of controlled brownouts starting Feb 28, 2026, for two weeks, after which the functionality will be fully removed on Mar 14, 2026.
During each brownout window:
All requests to generate OAuth 1.0 or implicit grant access tokens will fail with an HTTP 400 error code.
All requests authenticated with existing OAuth 1.0 or implicit grant access tokens will fail with an HTTP 401 error code.
Dates | Brownout duration per window | Brownout window start times (UTC) |
|---|---|---|
Feb 28, 2026 | 15 minutes | 00:00, 06:00, 12:00, 18:00
|
Mar 1, 2026 | ||
Mar 2, 2026 | 30 minutes | |
Mar 3, 2026 | ||
Mar 4, 2026 | 1 hour | |
Mar 5, 2026 | ||
Mar 6, 2026 | 2 hours | |
Mar 7, 2026 | ||
Mar 8, 2026 | 3 hours | |
Mar 9, 2026 | ||
Mar 10, 2026 | 4 hours | |
Mar 11, 2026 | ||
Mar 12, 2026 | 5 hours | |
Mar 13, 2026 | ||
Mar 14, 2026 | Final removal | |
After the brownout schedule completes on Mar 14, 2026, OAuth 1.0 and implicit grant flows and existing access tokens will no longer be usable.
To maintain access, migrate to a supported OAuth 2.0 flow by following our OAuth 2.0 guide which provides complete details.
We understand these changes require effort, and we're here to support you. If you have questions, need migration guidance, or run into issues, please https://support.atlassian.com/contact/.
As shared in our previous announcement, Bitbucket Cloud will fully sunset the cross-workspace APIs on April 14, 2026. We had previously communicated an earlier date but have decided to postpone this due to feedback from our partners.
To see the full list of affected APIs and the corresponding alternative APIs that we suggest transitioning to, please follow the “More details” section of this prior announcement. Based on feedback, we have also released a new API that allows you to list repository permissions in a workspace for a user.
To help teams identify and migrate any remaining usage ahead of the enforcement date, we will run a series of controlled brownouts starting March 23, 2026, for three weeks. During each brownout window, requests using the old cross-workspace APIs will be rejected, and affected endpoints will return a 410 Gone error. If you have made the switch to the new APIs, announced here, then you will not be impacted during the brownouts.
Date | Brownout duration per window | Brownout window start times (UTC) |
March 24, 2026 | 15 minutes | 00:00, 06:00, 12:00, 18:00 |
March 25, 2026 | ||
March 26, 2026 | ||
March 27, 2026 | 15 minutes | |
March 28, 2026 | ||
March 29, 2026 | ||
March 30, 2026 | 15 minutes | |
March 31, 2026 | ||
April 1, 2026 | ||
April 2, 2026 | 30 minutes | |
April 3, 2026 | ||
April 4, 2026 | ||
April 5, 2026 | 1 hour | |
April 6, 2026 | ||
April 7, 2026 | ||
April 8, 2026 | 2 hours | |
April 9, 2026 | ||
April 10, 2026 | ||
April 11, 2026 | 3 hours | |
April 12, 2026 | ||
April 13, 2026 | ||
April 14, 2026 | Final removal | |
During the brownout, if you encounter an error, please contact your app vendor. They will need to switch to using the new, support cross-workspace APIs.
After the brownout schedule completes, requests to the old cross-workspace APIs will stop working entirely at all time will no longer be supported starting April 14, 2026.
We understand these changes require effort, and we're here to support you. If you have questions, need migration guidance, or run into issues, please contact Atlassian Support.
As part of our wider announcement for deprecation of native Bitbucket Cloud Issues and Wikis, we will be removing API endpoints that support Issue Tracker in mid-August, 2026.
Expand the More Details view below to see the full list of endpoints being removed.
Here is the full list of endpoints for Issue Tracker that will be removed:
GET/repositories/{workspace}/{repo_slug}/components
GET/repositories/{workspace}/{repo_slug}/components/{component_id}
GET/repositories/{workspace}/{repo_slug}/issues
POST/repositories/{workspace}/{repo_slug}/issues
POST/repositories/{workspace}/{repo_slug}/issues/export
GET/repositories/{workspace}/{repo_slug}/issues/export/{repo_name}-issues-{task_id}.zip
GET/repositories/{workspace}/{repo_slug}/issues/import
POST/repositories/{workspace}/{repo_slug}/issues/import
GET/repositories/{workspace}/{repo_slug}/issues/{issue_id}
PUT/repositories/{workspace}/{repo_slug}/issues/{issue_id}
DEL/repositories/{workspace}/{repo_slug}/issues/{issue_id}
GET/repositories/{workspace}/{repo_slug}/issues/{issue_id}/attachments
POST/repositories/{workspace}/{repo_slug}/issues/{issue_id}/attachments
GET/repositories/{workspace}/{repo_slug}/issues/{issue_id}/attachments/{path}
DEL/repositories/{workspace}/{repo_slug}/issues/{issue_id}/attachments/{path}
GET/repositories/{workspace}/{repo_slug}/issues/{issue_id}/changes
POST/repositories/{workspace}/{repo_slug}/issues/{issue_id}/changes
GET/repositories/{workspace}/{repo_slug}/issues/{issue_id}/changes/{change_id}
GET/repositories/{workspace}/{repo_slug}/issues/{issue_id}/comments
POST/repositories/{workspace}/{repo_slug}/issues/{issue_id}/comments
GET/repositories/{workspace}/{repo_slug}/issues/{issue_id}/comments/{comment_id}
PUT/repositories/{workspace}/{repo_slug}/issues/{issue_id}/comments/{comment_id}
DEL/repositories/{workspace}/{repo_slug}/issues/{issue_id}/comments/{comment_id}
GET/repositories/{workspace}/{repo_slug}/issues/{issue_id}/vote
PUT/repositories/{workspace}/{repo_slug}/issues/{issue_id}/vote
DEL/repositories/{workspace}/{repo_slug}/issues/{issue_id}/vote
GET/repositories/{workspace}/{repo_slug}/issues/{issue_id}/watch
PUT/repositories/{workspace}/{repo_slug}/issues/{issue_id}/watch
DEL/repositories/{workspace}/{repo_slug}/issues/{issue_id}/watch
GET/repositories/{workspace}/{repo_slug}/milestones
GET/repositories/{workspace}/{repo_slug}/milestones/{milestone_id}
GET/repositories/{workspace}/{repo_slug}/versions
GET/repositories/{workspace}/{repo_slug}/versions/{version_id}
We are introducing baseline security requirements for Atlassian Government Cloud (AGC) apps, which will take effect on Mar 31, 2026. If you have any questions regarding these new standards, please contact us here: https://ecosystem.atlassian.net/servicedesk/customer/portal/34/group/109/create/579
We’re also publishing our annual update to the general Cloud App Security Requirements for 2026, which includes new provisions for AI security, data protection, and supply chain security. See More details for highlights on this update.
Key additions to the general Cloud App Security Requirements include:
AI Security: New requirements for apps using Forge Rovo actions and agents, including validating action inputs as untrusted, implementing permission checks for admin-level actions, and accurately configuring actionVerb values.
Data Protection:
External OAuth2 clients must use Forge's OAuth2 Providers and be configured as confidential clients where supported.
Application logs must strictly exclude PII, credentials, and sensitive data.
Apps must ensure strict tenant isolation during runtime.
Apps must not execute arbitrary code by spawning child processes (e.g., using Node.js child_process).
Application Security:
Apps using Forge SQL must use parameterized queries to mitigate SQL injection risks.
Updated guidance on Content Security Policy (CSP) regarding unsafe-inline and unsafe-eval directives.
Runtime Security:
Apps must not use EOL (end-of-life) Node.js runtimes.
Rate this page: