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.
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.
We've introduced two new components to UI Kit, now available in Preview: AtlassianTile and AtlassianIcon. Use these components to display Atlassian object type icons—such as stories, tasks, epics, blogs, and more—with consistent styling that aligns with the Atlassian Design System.
Both components provide fixed color, size, and styling options for Atlassian object types. Any updates to icon or tile styling in the Atlassian Design System are automatically reflected in your app.
For implementation details and examples, see the Atlassian icon and Atlassian tile component documentation.
The Connect Inspector service is moving to open source and also being deprecated. This service will no longer allow the creation of new temporary apps. Already registered temporary apps will stop recording new events, and old events will be deleted. Any apps already installed on developer sites will not be uninstalled.
Connect Inspector helped developers better understand Atlassian Connect lifecycle events and web-triggers. This service allowed developers to generate a temporary and unique Atlassian Connect app, which could be installed on a cloud development environment. This, in turn, let developers inspect the full request flow of a Connect app.
However, usage of the Connect Inspector has decreased significantly due to the following:
Atlassian Marketplace no longer accepts new Connect app listings
Local installs of Atlassian Connect apps will be locked from March 2026
Deprecating Connect Inspector allows the team to focus on Forge.
The Connect Inspector service will be discontinued by the end of February 2026.
Developers who still need similar functionality can use the open‑sourced version of the tool.
Atlassian Connect will reach end of support in December 2026. Migrate to Atlassian Forge for a more robust Events model.
We’ve added a new rovo.isEnabled method to the Forge UI bridge API. This method returns a boolean indicating whether Rovo is enabled for the tenant. You can use it alongside the existing rovo.open method to conditionally invoke Rovo only when it’s available.
For more information, see the updated documentation for the Rovo bridge methods.
We've added optional height and width properties to the Frame component in UI Kit. Apps can now set explicit dimensions in pixels or percentages, instead of relying on automatic resizing. This gives you more control over your app's layout.
For more information, see the updated documentation for the Frame component.
As part of end of support for Connect app, we will be deprecating addon linkers APIs.
On May 7, 2026 we will be removing the following endpoints:
GET /2.0/addon/linkers
GET /2.0/addon/linkers/{linker_key}
GET /2.0/addon/linkers/{linker_key}/values
PUT /2.0/addon/linkers/{linker_key}/values
POST /2.0/addon/linkers/{linker_key}/values
DEL /2.0/addon/linkers/{linker_key}/values
GET /2.0/addon/linkers/{linker_key}/values/{value_id}
DEL /2.0/addon/linkers/{linker_key}/values/{value_id}
Related brownout schedule notice: https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3139
We’re enforcing a set of OAuth and token-authentication changes for Bitbucket Cloud on May 4th, 2026. These updates improve security, align more closely with OAuth standards, and support long-term performance and scalability.
If your integration relies on any of the listed behaviours being deprecated, please update it before May 4th 2026. After the cutoff, requests using deprecated authentication patterns will no longer be accepted.
Changes to the client credentials grant flow
Client credentials grants will no longer issue refresh tokens; existing refresh tokens from this flow will expire or no longer be returned
Client credentials access from OAuth consumers owned by personal workspaces will only have access to data residing in the owning workspace.
Client credentials grants will authenticate as an app_user.
Changes to refresh tokens grant flow
Consumers must support rotating refresh tokens; each use of a refresh token will generate a new refresh token.
Unused refresh tokens will expire after 3 months, requiring full 3LO re-authorization.
Other changes to OAuth 2.0
OAuth token response payloads will return “scope" instead of “scopes".
OAuth access tokens can no longer be provided via query parameters or POST body. They must be sent exclusively in the Authorization header as a Bearer token.
All token based authenticated requests must be directed to https://api.bitbucket.org
Currently, Bitbucket issues a refresh token with the client credentials grant flow. Per https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.3 , refresh tokens should not be included. Issuing refresh tokens introduces security risks. They can be compromised and misused, while client credentials are intended for non-interactive, server-to-server use without long-lived tokens. To strengthen security and align with best practices, we will stop issuing refresh tokens for the client credentials grant flow. Any previously issued refresh tokens from this flow will expire, along with refresh tokens no longer being returned in the client credentials access token response on May 4th, 2026.
Stop expecting or using refresh tokens. Instead, re-authenticate directly using the client credentials grant flow as needed, it's simpler, more secure, and aligns with the intended use case
Currently, OAuth consumers owned by personal workspaces authenticate as the owning user when using the client_credentials grant, without permission restrictions or data filtering. This differs from team-based workspaces, where client_credentials access is already limited to data within the owning workspace. To improve security and ensure consistent behavior across workspace types, this will change.
Starting May 4th, 2026, client_credentials grants for OAuth consumers owned by personal workspaces will no longer authenticate as the owning user and will be restricted to accessing data only within the owning workspace.
Move to use an API token if you wish to access data outside of the owning workspace.
Previously, OAuth consumers owned by team-based workspaces using the client_credentials grant authenticated as a team user, with access limited to the owning workspace. However, OAuth consumers owned by personal workspaces using the client_credentials authenticate as the user who’s personal workspace it is.
After the cutoff date, client_credentials grants will authenticate as a dedicated app_user. Each app_user is unique per OAuth consumer and has the permissions to interact with workspace owning the OAuth consumer.
Actions performed (via our API) using these access tokens will be attributed to the app_user as the author, with the OAuth consumer’s name.
None
When refreshing an access token, a new refresh token is issued (replacing the old one). This standard security feature limits the lifespan of any single refresh token, reducing the window for compromise if a token is exposed.
When going through the refresh_token grant flow, always store the newly generated refresh token for future use. Once used once, the refresh token will expire after a short grace period.
Any attempt to make an access token via the refresh token grant flow using an expired refresh token will return a 400.
Refresh tokens that are not used within three months will expire, requiring users to complete the full three-legged OAuth flow again. This enhances security by preventing indefinite token validity and helps avoid large-scale token migrations in our systems.
None. Any attempt to make an access token via the refresh token grant flow using an expired refresh token will return a 400.
Our current access token response body use the key "scopes" for the list of granted permission scopes. The OAuth 2.0 specification (https://datatracker.ietf.org/doc/html/rfc6749#section-5.1 ) specifies that the key for this data should be named "scope". This is a minor fix, but one that aligns us with the spec for compliance and improved compatibility with standard OAuth libraries.
This new key “scope” will be start being returned along with the existing ”scopes" property from Feb 2, 2026 - as new properties are classified a non-breaking changes. Then, starting May 4th, 2026, we will return only the new key “scope".
Update parsing logic, if applicable, to expect "scope" instead of "scopes".
You can currently pass the access token via the access_token query parameter (in the URL) or as a POST form parameter named access_token . This is strongly discouraged in https://datatracker.ietf.org/doc/html/rfc6750#section-2.2due to security vulnerabilities: URLs are frequently logged in server access logs, browser histories, and proxies, increasing the risk of token exposure and theft.
To reduce these risks and promote secure practices, we are deprecating this mechanism. OAuth access tokens must now be sent exclusively in the Authorization header as a bearer token, as per https://datatracker.ietf.org/doc/html/rfc6750#section-2.1.
Ensure that you’re using authenticating with Bitbucket’s API using OAuth access tokens as bearer in the Authentication header.
Currently, some token-based authentication (this includes API tokens, app passwords, repository/project/workspace access tokens, and OAuth 2.0) can work against multiple endpoints like http://bitbucket.org, api.bitbucket.org, and https://bitbucket.org/api .
To improve performance, scalability, and consistency, we'll require all such requests to be directed exclusively to https://api.bitbucket.org after the cutoff. This consolidation helps optimize the infrastructure security controls.
Ensure that all requests are issued to the api.bitbucket.org sub-domain.
You can now set custom colors for UI Kit Visualisation charts. You can either set a color theme or assign colors to attributes. This can be done by passing the prop colorPalette into your chart.
For an example of how to implement this, please see the Forge UI Kit example app at https://bitbucket.org/atlassian/ui-kit-charts-example/src/master/.
For more information, see documentation.
Rate this page: