This page contains announcements and updates for developers from various products, platforms, and programs across Atlassian. It includes filter controls to make it easier to only see updates relevant to you.
To ensure you don’t miss any updates, we also provide RSS feeds. These feeds will take on any filters you applied to the page, and are a standardized way of keeping up-to-date with Atlassian changes for developers. For example, in Slack with the RSS app installed, you can type /feed <FEED URL> in any channel, and RSS updates will appear in that channel as they are posted.
Bitbucket Data Center and Server 8.19.26, 9.4.14 and 10.1.2 bug fix releases are available now!
To see the issues resolved in these bug fix releases, go to:
We’re retiring support for OAuth 1.0 and Implicit Grant flows for Bitbucket Cloud on Feb 27, 2026. These methods are being removed due to known security risks and alignment with modern OAuth 2.0 standards.
If you’re still using OAuth 1.0 please plan to migrate to Oauth 2.0 before Feb 27, 2026 using our authentication guide which has full details on how to set this up.
After the cutoff, requests using OAuth 1.0 or implicit grants will no longer be accepted.
For help migrating, see our updated authentication guide or contact support.
We’re happy to present the release of Jira Software and Jira Service Management 11.3. To find out more about breaking changes, new features, and introduced fixes, check out the Jira Software 11.3 release notes and Jira Service Management 11.3 release notes.
Download Jira Software 11.3 and Jira Service Management 11.3.
What’s new in Confluence Data Center 10.2 LTS?
10.2 is a Long Term Support release. More about Long Term Support Releases
Performance benchmarking report
Search and WebDAV strict patch settings limited to system admins
Cloud connectors for hybrid integrations
To explore 10.2, see Confluence 10.2 Release Notes.
You can now use UI modifications with the Project Picker field (com.atlassian.jira.plugin.system.customfieldtypes:project) in Jira. This enhancement allows you to customize the Project Picker field in the following views:
Issue view
Global issue create
Issue transition screens
This update makes it easier to tailor the user experience when working with project fields across key Jira workflows.
To use this feature, make sure you're using version 0.39.0 or later of @forge/jira-bridge.
For more information, see UI modifications documentation.
We’re deprecating the legacy GraphQL-based Forge storage APIs and the storage module in @forge/api, in favour of the new @forge/kvs SDK and REST APIs (released on March 2025).
This change impacts Forge apps that:
Use storage from the @forge/api package for KVS or Custom Entity Store, and/or
Access Forge storage from a remote service via GraphQL.
Deprecation period: 6 months from the date of this announcement.
After Jun 1, 2026, GraphQL endpoints for Forge storage will be removed and calls will start returning HTTP 410 Gone.
storage module in @forge/api is deprecated
The legacy storage APIs for Key-Value Store (KVS) and Custom Entity Store inside @forge/api are now deprecated.
All new storage features are only available through:
The @forge/kvs package for in-app usage, and
The KVS / Custom Entity Store REST APIs for remote usage.
GraphQL access to Forge storage is deprecated (native and remote)
GraphQL-based access to KVS and Custom Entity Store will be turned off after the deprecation period.
This applies to both:
Native calls made via storage in @forge/api, and
Remote calls made directly to the GraphQL endpoint.
We’re making this change now because:
Performance and reliability:
GraphQL adds significant overhead, which directly limits the throughput of the Forge Storage service. Removing GraphQL allows us to offer a more performant and reliable storage service.
REST is our long-term strategy for public Ecosystem APIs:
Atlassian is standardising on REST as the primary surface for public ecosystem APIs. Deprecating storage over GraphQL is an important step toward that consistent, REST-first platform.
Better developer experience with @forge/kvs:
The new @forge/kvs package provides:
Stronger typing via generics,
More predictable query and filter builders,
Support for new features (transactions, bulk operations, TTL, etc.) that will not be available on the legacy GraphQL-backed storage module.
Simplicity in our platform:
Removing the GraphQL path reduces operational complexity and lets us focus our engineering effort on a single, well-defined storage API.
If your Forge app uses storage from @forge/api
Migrate to the new @forge/kvs package.
Update all storage calls to use the new kvs builders (including query conditions, filters, and sorting).
Adjust error handling so missing keys use KEY_NOT_FOUND instead of UNDEFINED.
If your app accesses Forge storage from a remote via GraphQL
Move those integrations to the Forge Storage REST API for KVS and Custom Entity Store.
Replace GraphQL calls with equivalent REST endpoints and handle HTTP errors correctly (including 410 Gone after deprecation).
For step‑by‑step instructions and full code examples, see the official migration guide: https://developer.atlassian.com/platform/forge/storage-reference/kvs-migration-from-legacy/#migrating-to--forge-kvs-from-legacy-storage-module
If you maintain an app that still depends heavily on GraphQL for storage and believe migration within the deprecation period is at risk, please reach out via ECOHELP so we can work with you on a plan.
Starting with the following versions, major product releases will no longer support installing plugins that require transformation:
Confluence 11.0
Jira Software 12.0
Jira Service Management 12.0
Bamboo 13.0
Bitbucket 11.0
Crowd 8.0
For details, explore Transformed to transformerless plugin conversion.
Following the Preview release, the Forge Automation Actions is now generally available. The Automation action module allows you to extend the Automation Platform and add new Forge-based actions to your app. With this release Forge Actions can now output smart values, enabling seamless data flow and dynamic automation.
For more information, see the Forge Automation Action module documentation.
What’s Fixed?
We recently discovered an issue in the Transactions API that affected 2,166 paid transactions spread across Marketplace Partners. In these cases, Marketplace Promotion discounts—including their values and codes—were not displayed. This issue was limited to transactions processed through the new billing system for Cloud Apps and only impacted a small subset of transactions that included multiple discounts.
Data fields
This issue has now been resolved. Partners can now retrieve updated transaction details, including the applied Marketplace Promotion codes, by using the purchaseDetails.Discounts array with TYPE: MARKETPLACE_PROMOTION in the Transactions API.
Moving forward, transactions with Marketplace promotions will correctly display the associated discount amounts.
Next Steps:
Partners can fetch updated transactions data using the lastUpdated field in the Transactions API.
We've added a new optional hidden property to the Forge macro module. When you set "hidden": true in your macro definition, the macro will be hidden from the quick insert menu and macro browser. This prevents users from searching for and inserting the macro into new pages, but existing macros will continue to render as usual.
For more information, see Macro.
Context:
Any P2 plugin development using modern versions of Atlaskit will end up compiled-css.css files inside target/classes. We’ve been upgrading React & Atlaskit in the DC products and so many of the P2 plugins that make up our products now have a compiled-css.css file.
This made a long-standing bug with local development more obvious. The first compiled-css.css file found by the plugin system was used for all P2 plugins (instead of using the specific file from the respective plugin). https://compiledcssinjs.com/ compiles equivalent styles to the same CSS classname and there is decent, but not perfect overlap in styles. The result was that often just one Atlaskit component wouldn’t render correctly or any plugin-specific styles would be missing. This can be quite hard to debug because in the browser development tools it looks like the compiled-css.css file doesn’t change no matter what you do, this is of course because it’s using another plugins'.
Action:
We have fixed this long-standing underlying bug, but remained backwards compatible. To use the new, fixed local development system instead of the existing, buggy implementation you will need to use the upcoming post-2025-LTS product versions for local development (e.g. Confluence 10.3, e.g. Jira 11.4), and also upgrade QuickReload to 6.2.0+ (included in AMPS 9.7.2). If everything goes smoothly we will consider backporting to LTS releases of the products. Note: Crowd doesn’t have LTS releases, but it’s looking to be in Crowd 7.3
For more details read the original bug report: https://ecosystem.atlassian.net/browse/PLUG-981.
If you have any issues or questions, feel free to ask us on developer community.
Cheers,
Michael Kemp
Previously, the behavior of labels in Jira was inconsistent - some experiences treated labels as case-sensitive, while others did not. To provide a more predictable and unified experience, we are making labels case-insensitive in all grouped aggregations. This means that labels differing only by letter case (for example, "Bug" and "bug") will now be treated as the same label when aggregating data.
This update will be most noticeable on Jira dashboards and in Jira Work Management (JWM). No action is required from developers.
We’re announcing the deprecation of the V2 Reporting APIs on Atlassian Marketplace.
What’s changing
The Reporting APIs are now deprecated.
A six-month deprecation window begins immediately, and these APIs will be removed after May 31, 2026.
Refer to the updated documentation for V3 Reporting APIs to plan your transition.
What you need to do
Partners and developers should migrate to the V3 Reporting APIs to ensure continued functionality and support.
The requestRemote bridge API allows Forge apps to integrate directly with remote backends from the UI Kit and Custom UI applications via the Forge bridge.
This API is similar to invokeRemote, where requests include a Forge Invocation Token (FIT) as a bearer token in the authorization header; however, the request is not an official invocation that passes through the Forge platform. Therefore, requestRemote will not include OAuth tokens, even if configured for the remote, and will not be reflected in invocation metrics in the Developer Console.
For more details, see requestRemote.
The new Rolling releases feature is now available through Forge’s Early Access Program. To join the EAP, please complete this sign-up form.
Rolling releases let you decouple app permissions from app code, allowing code updates to be deployed independently of permission changes. This means your app can be upgraded to a new code version even if admins haven't approved new permissions yet, addressing the version fragmentation problem .
With rolling releases, developers can ship code improvements and bug fixes more frequently without being blocked by permission approval processes, while customers benefit from staying on current, secure versions. Admins maintain control by approving permission changes separately from code updates.
For more information on this feature, refer to the RFC-106: Future of Forge versioning - Permissions post.
EAP scope:
Available for Forge apps on Jira and Confluence only
Code-only upgrades via forge install --upgrade code
New Permissions SDK for runtime permission checks (@forge/react and @forge/api)
Current limitations:
Auto-upgrades not yet supported
Some upgrade paths unavailable (e.g., upgrading from free to paid)
Rate this page: