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.
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’re introducing display condition support to the following Jira Service Management (JSM) Forge portal modules as a preview release:
Portal footer
Portal header
Portal profile panel
Portal request create property panel
Portal request detail
Portal request detail panel
Portal request view action
Portal subheader
Portal user menu action
For these JSM modules, Forge apps can now declare displayConditions in the app manifest and have them evaluated by the host, consistent with how display conditions work for Jira and Confluence Forge modules today.
For further details, see the documentation here.
Support for Claude Opus 4.6 model is now available in Forge LLMs. This is in addition to the already supported Claude Opus 4.5 and Claude Opus 4.1 models.
Forge LLMs remain in Early Access (EAP). Due to high demand, participation is limited. To request access, join the waitlist here.
For the exhaustive list of supported models, refer to our documentation here
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.
Bitbucket Data Center and Server 8.19.27, 9.4.16, and 10.1.4 bug fix releases are available now!
To see the issues resolved in these bug fix releases, go to:
We previously announced on 18 December 2025 that the cleanHistory field in the Confluence Content Redaction APIs would be deprecated on 30 June 2026, and that the field would move from required to optional.
After further review, we’ve decided not to proceed with this deprecation. The cleanHistory field will not be deprecated at this time, and the field will remain optional. The behavior of the Content Redaction APIs remains unchanged.
The deprecation of the cleanHistory field previously announced in 18 December 2025 is no longer happening.
The cleanHistory field will continue to be supported in the Confluence Page and Blogpost Redaction APIs.
We are not making any breaking changes to how redaction requests are processed.
Existing implementations that include the cleanHistory field will continue to work as they did before the deprecation announcement.
You do not need to change how you call the Content Redaction APIs as a result of the previously announced deprecation.
If you already updated your integration to treat cleanHistory as optional or removed it from requests, those implementations will continue to function, but these changes are no longer required.
No action is required at this time. If we decide to revisit this deprecation in the future, we’ll provide advance notice and clear migration guidance via the Confluence Cloud changelog.
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.
A Confluence 11.0 EAP milestone is available now for testing. To find out what’s changed, check out Preparing for Confluence 11.0.
Got feedback or want to discuss the latest EAP? Chat with us in this Atlassian Developer Community thread. The earlier we know about potential problems, the more time we'll have to fix them before the final release.
Rollout : progressive rollout by tenant. IN PROGRESS
We've updated the behavior of the Create work type API. Previously, creating a work type automatically added it to the Default Work Type Scheme. This is no longer the case.
What's changing
Creating a work type no longer automatically associates it with the Default Work Type Scheme
You must explicitly associate work types to work type schemes using the Associate work type to a work type scheme API
What you need to do
If your integration relies on newly created work types being automatically available in the Default Work Type Scheme, update your code to explicitly associate work types after creation:
Create the work type using the Create work type API
Associate the work type to the desired work type scheme using the Associate work type to a work type scheme API
This change is not backward-compatible. Integrations that relied on automatic association may need updates to ensure work types are properly associated with schemes.
For more information, see:
Work types in the Jira Platform REST API documentation
Work type schemes in the Jira Platform REST API documentation
Community post: Project fields association improvements for additional context
Related: CHANGE-2527 (deprecation notice)
Rollout : IN PROGRESS
This change log ticket is a followup to https://ecosystem.atlassian.net/browse/CHANGE-2527 (where we announced a deprecation whereby all new fields now needed to be added to projects explicitly when created via API).
Change | Date |
|---|---|
All new fields will need to be added to projects explicitly when created via API (more details) | Feb 9, 2026- Feb 12, 2026 |
Create custom field: will no longer implicitly associate the field with all projects. It needs to be associated with the required contexts using the Create associations API.
Forge Containers is now available through Forge’s Early Access Program (EAP). To join the EAP, please complete this sign-up form.
This version of Forge Containers allows you to push, deploy, and execute container images as part of your app deployment. This allows your app to leverage a wide variety of runtime dependencies and languages within the container, perform long-running batch jobs, and access greater allocations of CPU and memory than what is available in the Forge Functions runtime.
For more information on this capability and how it works, see Forge Containers (EAP).
For apps with 500 or more installs, you can now download a CSV of all installations directly from the Installations page in the Developer Console.
We are upgrading from jQuery 3 to 4 in Jira 12, Confluence 11, Bitbucket 11, Bamboo 13, and Crowd 8. jQuery migrate will also be removed. Much frontend code depends on jQuery and we expect this will require upgrade work in apps (e.g. P2 plugins) and custom integrations with a frontend.
We consider this a breaking change and thus do not plan to backport to existing LTS releases.
This is to continue to meet customers' demands for secure & compliant products. We must be proactive in this upgrade because of how much our products and apps depend on it. We had many requests in the past to upgrade from jQuery 2 to 3, especially when there were vulnerabilities found in jQuery.
As we learn more and refine developer tooling to assist with the work, we will update the developer documentation
Many of the changes can be prepared for in a way that's backwards compatible with v3 so as many (compatible) changes as possible will also be backported to the LTS versions of Jira (11.3), Confluence (10.2), Bamboo (12.1) and to the latest versions of Bitbucket 10 and Crowd 7. The intention is to make it easier to test your app without having to worry about unrelated breaking changes.
Similarly, AUI 10.1 adds support for jQuery 4.
We will continue to provide jQuery web-resources and we ask developers to use them so that if needed we can roll out security patches as quickly as possible.
We are still early on in upgrading the Data Center products themselves. Future EAP versions will come with jQuery 4, but this might not arrive in the first few versions.
We have not currently noticed any JS behaviour nor signature changes that would affect apps. Please let us know if you spot something, and we will document it.
See the developer community announcement topic for more information and to leave feedback
Rate this page: