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 Cloud Platform.
For updates about changes to the Forge platform, see the Forge changelog in the Forge documentation.
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.
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.
Starting 15 Feb 2025, we will no longer accept a request body for the GET Issue Limit Report API. Any API calls made with a request body will result in a 403 error. If you are using a request body with this API, you will need to modify requests to avoid errors.
The API can still be used without a request body. By default, issues approaching the limit will be returned at the 80% threshold of the limit.
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.
The navigate and open methods from the @forge/bridge router API now allow you to programmatically navigate to select locations using a NavigationLocation object instead of a URL.
This capability is in Preview and is supported across Jira and Confluence modules for both UI Kit and Custom UI.
For more information on the NavigationLocation object, refer to the router documentation.
Update to the latest version of @forge/bridge with npm install --save @forge/bridge@latest
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
From Jul 7, 2025, we'll remove the ability to use the expands query parameter for fetching associated projects, workflows, issue types, and schemes in several Jira Cloud APIs. This change is necessary due to the absence of pagination, which can lead to scaling and reliability challenges on larger sites. On these sites, workflows, statuses, and schemes can be extensively interconnected, with numerous projects and issue types.
Once the removal comes into effect, we'll ignore the expands queries for this data and stop returning usage information in these APIs.
Affected APIs and parameters
Workflows:
Bulk get workflows: The ability to use the workflows.usages and statuses.usages expands will be deprecated.
Bulk create workflows: Usage information will no longer be included in responses.
Bulk update workflows: Usage information will no longer be included in responses.
Statuses:
Bulk get statuses: The usages and workflowUsages expands will be deprecated.
Search statuses paginated: The usages and workflowUsages expands will be deprecated.
Bulk create status: The usage and workflowUsages fields will no longer be returned.
Workflow schemes:
Bulk get workflow schemes: The workflows.usages parameter will be deprecated.
You may need to update your app as a result of this change - see the more details section.
Migrate to the new usage APIs announced as part of CHANGE-2292.
Until now, the first version of an app to adopt Forge features or migrate fully to Forge required admin approval in order to be upgraded on an existing installation site.
Connect apps moving to Forge can opt-in to have their existing Connect installations updated to their latest Forge version, as long as they do not have an elevation in permissions. The rollout will be staggered over 96 hours by default, but can be further staggered via the staged migration process.
Instructions on how to opt your app in to this feature and check its eligibility can be found at Minor version updates (Connect to Forge) (Preview).
The Rovo agent and action modules are now generally available.
Get started with the Build a Rovo Agent hello world app tutorial.
Jira Cloud now offers support for the jira:command module. This module allows apps to add items to the command palette. Users can also navigate to app-defined pages (such as jira:globalPage modules) or open custom modals. For more information, see the module documentation.
Rollout : progressive rollout by tenant in progress.
We are rolling out support for Connect rules (condition, validator, post function) and Forge rules (condition, validator, post function) in the new workflow editor for company-managed projects through a progressive rollout by tenant, starting in early February 2025.
Connect and Forge rules for the new workflow editor have already been enabled for all tenants in the Developer Canary Program.
Once app support for the new workflow editor is enabled, we expect apps using the documented workflow rule APIs to work without the need for changes:
All Marketplace workflow rules configured in the old workflow editor will automatically appear and become configurable in the new workflow editor.
Users will be able to create and configure Marketplace workflow rules in the new editor from scratch for company-managed workflows.
Workflows and workflow rules will continue to be editable in the old workflow editor.
The new workflow editor is a new experience that is already available to Jira Admins as an alternative to the old editor. Jira Admins can switch between the new and old editors, as well as change the default editor experience for company-managed projects.
Unlike the old editor, the new one previously did not support Marketplace workflow rules. With this change, Marketplace rules can now be added, viewed, and configured using the new workflow editor.
The new workflow editor doesn’t use drafts. Edits are made to the active workflow, changes are built up in the editing session and published with the update action.
The configuration in the context provided to marketplace rules will reflect pending changes. They won’t however be reflected in drafts. If your apps are reliant on drafts, some changes may be needed.
We’ve extended existing APIs to allow vendor rules to determine if the new workflow editor is being used.
For Connect
The callback passed to the getWorkflowConfiguration will receive the config as the first argument and a context object as a second argument in the new editor. The second argument will remain undefined in the legacy workflow editor.
1
2
3
jira.getWorkflowConfiguration( (config, context) => {
const isNewEditor = typeof context !== 'undefined';
} );
For Forge
An additional extension.isNewEditor key is set as true in the context object returned from the getContext API in the custom UI bridge. This key will continue to be unset in the legacy workflow editor.
1
2
const context = await view.getContext();
const isNewEditor = context.extension.isNewEditor || false;This change will be shipped for company-managed projects only. Marketplace rules for team-managed projects will be supported later, with more details to be shared in a separate announcement once available.
The long-term goal is to migrate all users to the new workflow editor once feature parity between the old and new workflow editors has been achieved. The old workflow editor will eventually be disabled. The timeline for this is not finalised yet, but it will happen no earlier than December 2025.
We've added a number of new APIs that can be used to find out what is using statuses, workflows, and workflow schemes. They allow you to page through the following:
These APIs will replace the usage expands in the workflow, status and workflow scheme APIs, so look for an upcoming deprecation notice shortly. When these deprecations happen, they’ll adhere to our deprecation policy.
We are removing mirrors of third-party packages such as maven-central from packages.atlassian.com
We're updating how we provide packages for customers and partners to develop with our platforms. Starting February 1, 2025, we will discontinue providing third-party packages on packages.atlassian.com. Instead, customers and partners must fetch these packages directly from the original upstream repositories.
For details on how this change affects you and for guidance on migration, please refer to the documentation available on Atlassian Developer .
The UI modifications (UIM) error handling method now supports a new error type - unregistered field.
The complete list of error types is available here.
We are shipping a new page that allows project admins to manage the fields associated in each of their team-managed projects.
The following APIs providing the fields parameter will be affected, with all and navigable field sets being narrowed down to only those fields that are explicitly added to the project.
Similar changes will be applied to webhooks, with the issue data that is sent by the webhook limited to the fields explicitly added to the project.
When these changes are rolled out, your app will need to:
Be able to handle receiving a partial list of fields that can differ between projects and between project/issue-types depending on the custom fields the admin has configured for each project and issue type
Be prepared for an admin potentially removing access to a required custom field from a project or project+issue type in which the app is used, at any time
This change will be rolled out progressively late February 2025 onwards. Please leave any further comments on https://community.developer.atlassian.com/t/rfc-70-project-fields-association-improvements-for-team-managed-projects/85254.
Rate this page: