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

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 March 31, 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.

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}

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.

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.

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.

Below is a table summarizing the deprecated APIs and the corresponding alternative APIs that we suggest transitioning to.

For the first three deprecated APIs, if you already have a single workspace, simply transition to the workspace-scoped alternative by including the workspace slug or UUID in the request path.

However, if you do not already have a single workspace, we suggest using the workspace‑scoped APIs in combination with the new /2.0/user/workspaces API.

1. Use the /2.0/user/workspaces to get all accessible workspaces for the user

2. Request to workspace‑scoped alternative endpoint (example: /2.0/repositories/{workspace})

   1. Option 1: select one accessible workspace to use in a request to the scoped endpoint (1 request)

   2. Option 2: make a request for each accessible workspace and aggregate the results (N requests)

Note that we will not introduce any additional APIs that can get a user’s repositories across multiple workspaces. All requests to get repository information must be single workspace-scoped going forward.

To access these components, you will need to update your app to the latest version of @forge/react. In the terminal of your project directory, run:

npm install --save @forge/react@latest