This page includes release notes and updates for Jira Cloud app developers. Use this page to keep track of upcoming changes, deprecation notices, new features, and feature updates from Jira Service Management Cloud.
Go to our developer community to ask questions. You may also be interested in the What's New blog for Atlassian Cloud where details of major changes that affect all users of the Jira Cloud products are announced.
After the beta phase of Atlassian’s new navigation, we’re thrilled to announce its General Availability (GA) for Jira, Jira Service Management, Jira Product Discovery, Confluence, and Atlassian Home. In this article, you’ll find key details about what’s changing with the new navigation, Jira and Jira Service Management apps, as well as when those changes will go live.
Starting Sep 17, 2025, the ability to publish a new Jira or Confluence app using a JSON Connect descriptor to the Atlassian Marketplace will be deprecated. This change is part of our strategic shift to the Forge platform that enables developers to leverage enhanced capabilities such as Forge Storage.
Partners should plan to list any Connect apps currently under development on the Atlassian Marketplace by Sep 16, 2025, and should undertake all new app development on Forge.
Documentation on adopting Forge from Connect, capabilities equivalences between Forge and Connect, and other details about the transition from Connect to Forge for Jira and Confluence apps are available on the Adopting Forge from Connect content site.
Today we published Announcing Connect End of Support: Timeline and Next Steps, following up on our earlier blog post Taking the Ecosystem Forward: An Update on the Future of Connect.
This announcement is intended for developers of Connect apps, including partners and customers with custom apps. It provides a detailed view of the phases and timing for the end of support of Connect.
In the latest version of @forge/react, we're adding a new disableSubmitOnEnter property to the UI Kit Jira component, CustomFieldEdit. The property can be used to disable the submission of the field value when the “Enter” key is pressed.
For more information on this component, see the component documentation.
To update your UI kit app to the latest version, run the following command in your project directory:
npm install --save @forge/react@latest
Forge Remote Data Residency realm migrations is now available in Preview. This release provides apps with the ability to support customer-initiated migrations between data residency regions.
Please review the documentation to learn more about how to support realm migrations in your app.
All data residency migration lifecycle requests will now include an additional migrationId field to support improved tracking, reporting and monitoring of migration requests.
To improve performance and address constantly evolving threats on the web, Atlassian is enabling AWS Cloudfront Content Delivery Network (CDN) and Web Application Firewall (WAF) for all Confluence and Jira Cloud Customers.
A side effect of this change is the deprecation of the following three ciphers:
1
2
3
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384For the list of currently supported ciphers, please visit https://support.atlassian.com/security-and-access-policies/docs/supported-security-protocols-for-atlassian-cloud-products/ .
This change may impact 12+ year old systems under some conditions. Click more details for further information.
Windows Server 2012 (including R2) and Windows 8.1 native applications (such as Internet Explorer or Invoke-WebRequest) that rely on the inbuilt schannel may fail to interact with Jira and Confluence Cloud.
To resolve the problem, use an updated browser, including Chrome, Firefox, Edge, etc.
For curl and libcurl and other HTTP libraries, use a cross-compiled version that uses LibreSSL or OpenSSL.
Update to Windows Server 2016 or Windows 10 or later.
Alter your software to use an alternative HTTP/SSL/TLS library, or write it in a language which can use LibreSSL or OpenSSL or BoringSSL e.g. libcurl, Python, Node, Java, Go etc.
Add a small HTTP proxy between your application and Jira/Confluence Cloud (e.g. Nginx, HAProxy, Caddy, Traefik, Kong) that can negotiate TLS on behalf of your application. (Specific instructions on how to achieve this are not provided here).
Use the hosts file to pin your Jira/Confluence domain to our old IPs:
https://www.howtogeek.com/27350/beginner-geek-how-to-edit-your-hosts-file/
Note: These old IPs will only be available until October 2025.
US 104.192.142.18
Europe 185.166.143.36
Asia 13.200.41.128
For more information please see: https://community.atlassian.com/forums/Atlassian-Platform-articles/Windows-Server-2012-and-Windows-8-SSL-TLS-handshake-fails-with/ba-p/2967467#M152
Following the deprecation announcement on 28 Aug 2024, we have now removed UI Kit 1 from the Forge platform.
For apps still using UI Kit 1, customers will see that their app version is outdated due to a deprecated platform component.
You will need to upgrade to the latest version of UI Kit for your app to work. If you are in the process of upgrading your UI Kit 1 app, please refer to these resources to guide you through the transition:
UPDATE, 02 Mar, 2025 The scheduled upgrade was successfully performed on March 02, 2025 between 12:30 AM to 03:30 AM UTC, and we have verified that all the capabilities mentioned below are working as expected. If you are experiencing ongoing issues with these capabilities please contact your local Atlassian site administrator. If you need further help, please raise a support ticket at https://support.atlassian.com/#contact.
EDIT, 28 Feb, 2025 : Please note that below mentioned times are UTC i.e. 02 Mar, 2025 between 12:30 am to 03:30 AM UTC
Forge platform will be undergoing maintenance on March 02, 2025 between 00:30 AM to 03:30 AM. During this interval, below capabilities will not be available intermittently:
Create/update/delete apps
Deploy apps
Install/uninstall/upgrade apps
View existing installations
App invocations will continue to work for existing users of the apps. However, new customers might not be able to use apps as consent process will be impacted during this interval as well.
App activity logs are coming to Atlassian audit logs at the end of Feb 2025 for all admins with Atlassian Guard Premium or Cloud Enterprise licenses.
App activity logs record activity by third-party apps in the form of API calls to Jira and Confluence.
We will show app API calls for Connect, Forge and 3LO apps and related response code as well as information about whether the call was made asApp or asUser.
Admins will be able to search and filter for the app API logs through the audit log UI. To do so, they can use the ‘search’ bar or ‘activities’ filter.
Alternatively, admins can choose to register for a webhook to stream the API logs to their preferred destination for further analysis or integrate with a threat detection tool they may use.
Finally, there is also the option to use the audit log API to receive app activity logs
Jira and Confluence Cloud APIs use TLS and HTTPS.
Historically the TLS certificate presented to clients used “DigiCert Global Root G2” as the root certificate.
Now, Amazon Root CA 1 has been added as a root certificate.
For almost all customers that use common CA trust stores including Linux (e.g Ubuntu and others), Mozilla, Apple, Windows, BSD etc, both these root certificates are already present and there is no action required.
For the small number of customers which have manually configured certificate pinning, or for systems which do not use common CA trust stores, Amazon Root CA 1 can be downloaded fromhttps://www.amazontrust.com/repository/. Installation steps for the root certificate will be unique to your software and are not described here.
For emphasis, the extreme majority of clients use common CA trust stores. Unless certificate pinning has been specifically configured on your API client, or the API client software specifically requires the installation of a root certificate, there is no action required.
Update Feb 28, 2025 :
Some systems may need to install Starfield Services Root Certificate Authority - G2 from https://www.amazontrust.com/repository/ in their Trusted Root Certification Authorities Store if it is not present. This can occur if Amazon Root CA 1 is present as an intermediate certificate signed by Starfield, or a Windows system is unable to dynamically retrieve the correct Root Certificate from Microsoft. Further details can be found here: https://aws.amazon.com/blogs/security/acm-will-no-longer-cross-sign-certificates-with-starfield-class-2-starting-august-2024/.
To improve performance and address constantly evolving threats on the web, Atlassian is enabling AWS Cloudfront Content Delivery Network (CDN) and Web Application Firewall (WAF) for all Confluence and Jira Cloud Customers.
This rollout will occur over the next few months, country by country, progressively, with each country taking around 1-2 weeks to complete the migration.
This improvement may unfortunately impact some Jira and Confluence Cloud API integrations (like those written in Python, Node/JS, Java, libcurl, Axios, atlassian-connect-express etc) that attempt to make requests with URLs (including path and query string) longer than 8192 characters/bytes.
Where previously Jira and Confluence Cloud APIs handled paths longer than 8192 characters/bytes, AWS Cloudfront will actively reject such requests:
The maximum length of this URL is 8192 bytes.
If a request or a URL exceeds these maximums, CloudFront returns HTTP status code 413, Request Entity Too Large, to the viewer, and then terminates the TCP connection to the viewer.
Unfortunately, it is not possible to configure Cloudfront to allow longer URLs.
Atlassian products such as Loom, Trello, Opsgenie, Statuspage etc already reject 8192 characters/bytes urls.
For resolution instructions see more details below.
To resolve the issue, break up API calls into multiple requests, or restructure your API call such as using labels or field filters instead of enumerating individual work items.
I saw the error in my Chrome/Firefox/Edge/Safari etc browser
If you observed the aforementioned error in your browser please contact Atlassian Support, and ideally include the full text of the error, including Trace ID, and a HAR file covering the error: https://confluence.atlassian.com/kb/generating-har-files-and-analyzing-web-requests-720420612.html
We have recently noticed an unusual increase in API usage. In order to maintain reliable services for both Atlassian customers and partners, we will begin enforcing more granular rate limits for Confluence and Jira APIs.
We will begin enforcing REST API (Quota and Burst based) rate limits for all free apps on or after August 18, 2025. We have added additional headers to provide further transparency. Please monitor header responses to see where you are at with regard to limits.
In some circumstances where apps are highly impacting the stability of our platform, we reserve the right to enforce the limits at an earlier date. We will notify your listed contact via email if you are impacted. Additionally, we are planning to bring clarity to rate limits across our platform infrastructure over the next year, including paid apps.
We recommend all customers and partners ensure they're not exceeding the rate limits so that they do not get impacted at a later date.
Learn more about the header responses and read relevant FAQs about rate limiting adjustments for Jira here and Confluence here.
We will remove support for Automation incoming webhooks that reference the automation.atlassian.com domain. Webhooks created before 28 January 2025 are affected. Applications that trigger rules via those incoming webhooks will need to change the URL they use, and add an additional HTTP header. Expand the details for more information.
We're updating the incoming webhooks trigger in Atlassian automation. This update is part of our continuous focus to uplift the security and reliability of automation.
We are deprecating the domain automation.atlassian.com for incoming webhooks, and replacing it with a more secure endpoint in a different domain. The URLs to trigger webhooks have a different structure, and an additional HTTP header is required. The webhooks that use the old domain automation.atlassian.com will stop working on 30 May 2025.
All new rules created since 28 January 2025 are already using the new endpoint and header, and no action is required.
Rules with incoming webhooks created before 28 January 2025 will work normally until 30 May 2025 without any change. However, for these rules to continue working after that date, manual changes are required to use the new endpoint before 30 May 2025.
To migrate existing rules to the new endpoint, follow these steps:
Open the Automation rule list in Jira or Confluence.
Click on the ‘Trigger' filter and select the ‘Incoming webhook’ filter. All rules containing an incoming webhook trigger will be shown.
Open one of these rules in the rulebuilder and select the trigger component.
Copy the new URL and secret.
Enter the new URL and secret into your connected application, and add a new HTTP header with the name X-Automation-Webhook-Token. The method to do this can vary between applications, so you may need to check what the instructions are for your application. If your application does not support custom HTTP headers, you can instead insert a slash at the end of the URL and add the secret after this. For example, https://URL/SECRET. This will allow you to update your rules without the need for a HTTP header. However, we recommend using the header if possible, as it provides more security for your secret.
You can verify if the new URL successfully triggered your rule by visiting the audit log after it runs.
Repeat the above steps for all rules containing an incoming webhook trigger.
To improve performance and address constantly evolving threats on the web, Atlassian is enabling AWS Cloudfront Content Delivery Network (CDN) and Web Application Firewall (WAF) for all Confluence and Jira Cloud customers.
This rollout will occur over the coming months, country by country, with each country taking around 1-2 weeks to complete the migration.
This improvement may unfortunately impact a small number of Jira and Confluence Cloud API integrations (like those written in Python, Node/JS, Java, libcurl, Axios, atlassian-connect-express, etc) that are accidentally including a body/data/payload in GET requests.
Such requests will no longer have their body payload silently discarded and continue to be processed. Instead, they will be rejected with a HTTP 403 response code.
Atlassian products such as Loom, Trello, Opsgenie, Statuspage etc already reject GET requests with Body payloads.
For resolution instructions see more details below.
Previously Jira and Confluence Cloud APIs silently discarded any body included with a HTTP GET request and continued to process the request as normal. Unfortunately, AWS Cloudfront will actively reject such requests:
If a viewer
GETrequest includes a body, CloudFront returns an HTTP status code 403 (Forbidden) to the viewer.
HTTP clients (other than browsers) that attempt to include a body with a GET request will observe a HTTP 403 response code, with text like the following:
1
2
3
4
5
6
7
8
9
403 ERROR
The request could not be satisfied.
Request blocked. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner. If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront)
Request ID: L23_HKTRmXpYbGS8c9dcwq-Zy5fx3_a7htuNzMlvJE6rW814efVx2h==Unfortunately, it is not possible to configure Cloudfront to preserve the existing silent discard behavior which previously allowed these malformed requests to be successful.
To resolve the issue ensure that your HTTP client code for your API integration does not include any body with its GET requests. These are never necessary and were previously discarded.
We have found that some developers are not even aware their program or script is including a body with a GET, and the most common body payloads are as follows:
1
2
3
4
5
{}
""
''
If you observed the aforementioned error in your browser then the underlying cause is different, as browsers do not send GET requests with a body.
Please contact Atlassian Support, and ideally include the full text of the error, including Trace ID, and a HAR file covering the error: https://confluence.atlassian.com/kb/generating-har-files-and-analyzing-web-requests-720420612.html
Rate this page: