Last updated Jul 5, 2024


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.

5 July 2024

Added Forge remote is now available for Forge functions (preview)

Forge functions can now interact with remote backends utilising Forge Remote. This capability makes it simpler and more secure to integrate remote backends with your Forge app.

See Forge Remote - Calling a remote backend from a Forge function for more information.

15 May 2024

Added requestBitbucket is now available in @forge/bridge

  1. requestBitbucket is now available in @forge/bridge, so you can make Bitbucket API fetch requests from the front end of a UI Kit or custom UI app. For more information on using requestBitbucket, see the Part 2: Call a Bitbucket API tutorial.

23 April 2024

Announcement Dynamic Pipelines for Bitbucket Cloud are now available

Dynamic Pipelines for Bitbucket Cloud are now generally available.

More details

Dynamic Pipelines allow you to utilise Forge functions to augment and modify CI/CD workflows at runtime, implementing sophisticated dynamic logic that will enable unparalleled levels of CI/CD control.

For more info, check out the announcement post.

22 April 2024

Announcement Bitbucket custom merge checks are now in General Availability (GA)

Custom merge checks are now generally available in Bitbucket Cloud. For full details on all the changes coming as part of this release, refer to our deep-dive blog post.

This release includes the following changes:

  • Repository Admins:

    • Custom merge checks can now be configured as either “recommended” or “required”.

    • “Recommended” checks will provide feedback to the PR author if failing, but will not block the merge.

    • “Required” checks will block the PR if failing.

    • As per existing classic merge checks, setting custom merge checks as “Required” is only available in premium workspaces.

  • Pull request reviewers/authors:

    • Classic merge check and custom merge check results have been consolidated into a single UI Element on the Pull Request screen.

    • The UI behaviour of classic merge checks has been updated to be consistent with the design of custom merge checks.

    • Failing “recommended” merge checks will be visible on the check result sidebar card with a unique visual indicator.

    • Custom merge checks that run “on-merge” have been more clearly distinguished from conventional “pre-merge” checks on the checks result sidebar card.

19 April 2024

Added Pull request task REST APIs

Introducing new REST API endpoints to facilitate the management of pull request tasks. For further details, please refer to the documentation:

11 April 2024

Added App access rule under data security policies: Data security policy events upper limit

The progressive rollout of data security policy events has been completed. Data security policy events are generated when installed apps' access to certain data within Confluence, Jira, Jira Service Management, or Jira Software has been blocked by an administrative policy with an App access rule. You can now subscribe to these events.

Being a new capability however, we are scaling up our processing of these data security policy events over the next few months. In the meantime we have set a upper limit of 50,000 objects. This means that if a customer activates or updates a data security policy that affects more than 50,000 objects, you will receive the first 50k objects in the events and the rest would be omitted.

We intend to raise these limits and will advise once we have reached our final threshold— and have determined our final hard limits.

More details

Data security policies help customers keep their organization’s data secure by letting them govern how users, apps, and people outside of their organization can interact with content such as Confluence pages and Jira issues.

The new app access rule under data security policies allows customers to restrict app access to the content in Confluence spaces or Jira projects under a given policy. In this way, customers can benefit from apps while still limiting 3rd-party app access to certain content in select spaces.

If you are looking to update your apps with custom in-app messaging whenever your app is affected by an app access rule, we encourage you to use the Developer guide.

28 March 2024

Announcement Staged rollout started for Forge hosted storage data residency (beta)

We have started the rollout of data residency for Forge hosted storage, where data will be moving to the same location as the host product. To ensure a smooth rollout, we will be rolling out the feature to customers gradually over the next month.

Once the rollout is complete, Forge hosted storage data will be stored in the same location as the host product for all new and existing Forge apps, for all current and future Atlassian-supported locations. We will let you know when the rollout is complete.

Action Required
Last month, we outlined some actions required to prepare for this rollout (see changelog for more information). If you haven’t done so yet, we recommend:

  1. redeploying any app that uses Forge-hosted storage

  2. updating the manifest for any apps that use remotes or external permissions (for details about how to do this, see our documentation).

At the end of the staged rollout, we also recommend updating the Privacy & Security tab for any app that exclusively uses Forge hosted storage for in-scope End User Data, to indicate that your app supports data residency. You should also define in your app documentation what data is in-scope and out-of-scope. This way you can let customers know about your app’s support for data residency. We will let you know when to make this update.

More details

Data residency for Forge-hosted storage is the latest milestone on our shared mission to offer enterprise-ready apps to customers in the cloud. With data residency available for Forge-hosted storage, meeting a key customer trust requirement will be easier than ever.

It’s important to note that, as we shared last November, when data residency reaches beta for Forge-hosted storage, app data stored in Forge-hosted storage will automatically inherit data residency in all current and future regions supported by the host product. This will not be reversible.

Read more about data residency for Forge hosted storage.

27 March 2024

Added Pull request page merge button UI updates

We have updated the ‘Merge’ button on the pull request page. Now, when there are failing pre-merge checks preventing a pull request from being merged, the ‘Merge’ button will be yellow with a warning icon.

25 March 2024

Announcement Scope check for bitbucket:mergeCheck module now enforced at runtime

As mentioned in the previous announcement, if your Forge app has the bitbucket:mergeCheck module, it needs to include the read:pullrequest:bitbucket scope.

This is now enforced at runtime. If you deploy an app containing bitbucket:mergeCheck module without the read:pullrequest:bitbucket scope, the app’s mergeCheck functions will fail to be invoked.

Make sure that you:

  1. Update your app manifest.

  2. Redeploy via forge deploy.

  3. Update the app installations via forge install --upgrade.

20 March 2024

Announcement Forge remote (preview) is now available for Bitbucket Custom Merge Check module

When creating custom merge checks for Bitbucket Cloud, you can now use a remote endpoint in place of a hosted function.

You can optionally configure your to receive an appSystemToken which can be used to make API requests back to Bitbucket APIs and Forge storage.

See for more information.

5 March 2024

Announcement bitbucket:mergeCheck module now requires read:pullrequest:bitbucket scope

Forge apps using the bitbucket:mergeCheck module will now require the read:pullrequest:bitbucket scope in their manifest.

When deploying an app, if the read:pullrequest:bitbucket scope is not in the manifest, the forge deploy command will fail.

In a few weeks, the read:pullrequest:bitbucket scope will be enforced at runtime. This means that, if the scope is not present in the deployed and installed version of an app, the app checks function will fail to be invoked.

In preparation for this change, we recommend:

  • deploying the app with the additional scope to each environment, production included

  • install the deployed version of the app via forge install --upgrade to every workspace for each environment

  • apps distributed to customers will need to be upgraded by following the steps here:

Another changelog will be posted when the scope is enforced at runtime.

If you have any questions, please add a comment to the community post.

Announcement @forge/react version 10 release

As part of our preview release of Forge UI Kit 2, we're releasing a new major version of @forge/react with 37 updated components.

From version 10 onwards, existing component APIs are now updated, and a range of new components are now supported in UI Kit 2. For more details, see our documentation here.

The new version is supported within the following products:

  • Confluence

  • Jira

  • Bitbucket

  • Compass

Updating to the latest version may contain breaking changes for existing UI Kit 2 apps, as all existing component APIs have been updated. The breaking changes are only applicable if you choose to upgrade your UI Kit 2 apps.

Our component documentation contains more details on the props each component will now take.

To update your UI Kit 2 app to the latest version, in the terminal from your project directory, run the following command:

npm install --save @forge/react@latest

If you’re still using older versions of UI kit, such as the previous version of UI Kit 2 (@forge/react version 9) and UI Kit 1, you can find their corresponding documentation here.

1 March 2024

Early Access New custom merge check trigger for reviewer status changes

We added a new on-reviewer-status-changed trigger type for Bitbucket Custom Merge Checks (currently available under EAP). You can use this trigger type to invoke your check whenever a reviewer status changes. See the Custom merge check (EAP) - Triggers page for details.

16 February 2024

Announcement Bitbucket integration is now in General Availability (GA)

Bitbucket integration with Forge is now fully supported, with a minimum 6-month deprecation period for breaking changes. All Bitbucket modules are now released under GA as well (except for Custom merge checks, which is still available only under EAP right now).

For more information on Forge release stages, see:

23 January 2024

Added @forge/bitbucket package to assist developing Forge apps on Bitbucket

We've published a new package, @forge/bitbucket, to aid the development of Forge apps on Bitbucket.

The package provides helper functions that developers may frequently use when creating their Forge apps. See the package documentation for more information.

Rate this page: