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.
We’re introducing the ability for apps to publish events, allowing for enhanced interoperability between apps. This feature enables apps to subscribe to events using the existing https://developer.atlassian.com/platform/forge/manifest-reference/modules/trigger/ module, opening up new possibilities for app interactions.
Developers can start using app events by implementing the https://developer.atlassian.com/platform/forge/manifest-reference/modules/event/ module in their apps. For detailed guidance and examples, refer to https://developer.atlassian.com/platform/forge/events-reference/app-events/.
To publish events using the runtime API, you need at least version 2.0.0 of the @forge/events dependency. Add this to your package.json:
1
2
3
4
5
{
"dependencies": {
"@forge/events": "^2.0.0"
}
}We have enhanced Bulk Move API to allow users to move both parent and child work items/issues in a single request, as well as move multiple work items/issues of different types in the same request.
Starting on September 29, 2025, the JSM Create organization public API, will no longer sanitize the name value, and will instead perform an exact match on the name value supplied by the caller while finding an existing organization by name.
JSM will also start applying a new validation rule when creating new organizations. Requests in which the name field contains extra whitespaces at the start, end or in-between, will fail with an HTTP 400 code.
Valid name examples: Test organization , Support User Group
Invalid name examples: Test organization , Support user group
The JSM Create organization public API currently sanitizes the supplied ‘name’ value by removing extra whitespaces at the start, end, or in between. Going forward, we’re making the following changes to the sanitization and validation logic for the name field from the request body.
Current behavior:
The value of the name field in the request body can contain extra whitespaces at the start, end, or in between. JSM sanitizes the name and creates a new organization if an organization with the sanitized name doesn’t already exist. (Example: My org is considered a valid name and will be sanitized to My Org while getting existing or creating a new organization).
New behavior:
JSM won’t sanitize the name value and will find the existing organization for the exact name value sent by the caller.
If the existing organization isn’t found, JSM’ll apply the new validation rule below and create a new organization only if the validation passes.
New validation rule: Check for extra spaces in the name value, and fail the request with a 400 Bad Request error if there’re extra whitespaces at the start, end, or in between. (Note: A single in-between whitespace is valid; for example, test organization is valid.)
Reasons for this change:
We’re rolling out the JSM SCIM provisioning feature which allows admins to manage customer organizations in external IdP and provision them to JSM. Custom sanitization logic for names can’t be applied for organizations synced from external IdP since JSM is expected to match the exact value of the organization name from IdP.
The new validation rule is required to ensure that a new organization doesn’t get created inadvertently for existing public API callers who rely on sanitization logic to remove whitespaces and find an existing organization on their JSM site.
Ways to fix your app or caller program:
Remove leading, trailing, or multiple in-between whitespaces while creating a new customer organization.
Send an exact match for the name field (without additional whitespaces) if you intend to get the existing organization by name.
We have published a new migration guide to assist you in transitioning your Forge custom fields to use the isInline property.
The guide includes two practical examples:
Migrating a Forge custom field to render inline
Migrating a Forge custom field to render in a modal
For more details, please refer to https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field/#inline-edit-migration-guide
Blob objects can now be sent and received via the events API. This enhancement allows for more efficient data handling and transmission within the API.
Update to the latest version of @forge/bridge with npm install --save @forge/bridge@latest
We’ve added additional project information to the extension context for Forge custom fields on Jira Service Management portal requests. This allows accessing project.id directly from the extension data to avoid unnecessary REST API calls.
On February 10th 2025, we announced the Deprecation of automation.atlassian.com incoming webhooks for Automation rules https://developer.atlassian.com/changelog/#CHANGE-2299. As of 30 May 2025, the legacy incoming webhook has now been deprecated.
We’ve started to gradually shut down the legacy endpoint across all customer sites. Rules recently triggered through legacy webhooks will now be marked with error icons.
To view impacted rules:
Open the automation rule list in Jira or Confluence.
Click on the ‘Trigger' filter and select the ‘Incoming webhook’ filter. All rules triggered by an incoming webhook will be shown.
Within these filtered rules, any which have recently been triggered through a legacy webhook will have a error icon next to their name. This shows which rules were unable to complete a successful run due to using the legacy URL.
To learn how to update these rules, you can read our support documentation.
Since incoming webhooks may be called from non-Atlassian systems that we don’t have access to, or aren’t aware of, rule owners will need to migrate impacted rules to the new endpoint manually, read our support documentation.
Atlassian font assets are now being preloaded by the Connect JS library (ACJS) to support consistent typography across Atlassian and Connect apps. These assets are served from dedicated design system CDN https://ds-cdn.prod-east.frontend.public.atl-paas.net.
Connect apps using the standard all.js ACJS bundle will now automatically pre-load:
atlassian-fonts.css
Atlassian Sans font files (e.g., AtlassianSans-latin.woff2)
These files are delivered from the new ds-cdn host. The change was previously gated and is now enabled for all Connect apps.
Apps with a strict Content Security Policy (CSP) must update their style-src and font-src directives to allow the new CDN host. Without this, CSP violations may block font and styles loading.
Update your CSP to include:
1
2
style-src https://ds-cdn.prod-east.frontend.public.atl-paas.net
font-src https://ds-cdn.prod-east.frontend.public.atl-paas.net This change improves visual alignment with Atlassian’s visual refresh program. For further background, see:
With the Forge CLI 11.5.0 release, we've enhanced the Forge platform to let you specify the memory available to functions at runtime by setting the memoryMB property in the Manifest (https://developer.atlassian.com/platform/forge/manifest-reference/#runtimev2) . Increasing the function memory also increases its CPU allocation. The memory value can now be set between 128 MB and 1,024 MB, doubling the previous limit of 512 MB. If you do not configure the function memory, the default memory allocation of 512MB applies to your function. This change helps address out-of-memory (OOM) issues by allowing higher memory allocation.
For more information on configuring Forge function memory, see https://developer.atlassian.com/platform/forge/manifest-reference/#runtimev2.
For details on the relationship between memory and CPU allocation, refer to the https://docs.aws.amazon.com/lambda/latest/dg/configuration-memory.html.
We've released support for all Forge custom field types on Jira Service Management portal requests. To use Custom UI or UI Kit for app rendering, specify the portal-request experience in the edit entry point. This change aims to enhance the flexibility and functionality of custom fields in the Jira Service Management portal.
Developers should follow the https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field/#portal-request--preview- to implement this feature. Please note that anonymous access and Jira Service Management portal view support are coming soon.
We’re notifying you regarding the use of API tokens. Starting November 22, 2025, Atlassian will implement rate limits for API tokens to ensure a consistent, reliable, and secure experience for all users.
If you are using API tokens, please review this documentation to learn more about the limits
In some circumstances, where integrations using API tokens heavily impact the stability of our platform, we reserve the right to enforce the limits at an earlier date. If you will be rate-limited before November 22, 2025, Atlassian will contact you directly.
The introduction of rate limits is a proactive measure to safeguard our platform's stability and security. Rate limits help ensure platform stability and reliability by preventing integrations from overloading Atlassian’s systems.
This change is made to close a security issue. The following GET JSM attachment APIs have been updated to respect the more fine-grained comment visibility
/rest/servicedeskapi/request/{issueIdOrKey}/attachment/{attachmentId}
/rest/servicedeskapi/request/{issueIdOrKey}/attachment/{attachmentId}/thumbnail
internalattachments are now filtered and returned only the ones visible to the (API) user.
publicattachments are returned the same way prior to this change.
If comment visibility is not set, the same result is returned as before prior to this change, respecting internal/public attribute.
We previously announced the deprecation of the modal experience for Forge custom fields on the Issue view, which was scheduled to take effect on April 1, 2025. We understand the importance of this transition and have decided to extend the deprecation period to August 1, 2025. This extension is intended to provide additional time for developers to adapt to the new inline rendering mode.
During this extended period, apps that continue to use the deprecated modal experience will display a warning message. This message will inform users that the app is relying on a deprecated feature and advise them to contact their system admin or app developer for an update.
Please note that this will be the final extension. After August 1, 2025, rendering fields in the modal will only be possible using the dedicated https://developer.atlassian.com/platform/forge/ui-kit/components/modal/ or https://developer.atlassian.com/platform/forge/apis-reference/ui-api-bridge/modal/.
We encourage all developers to make the necessary adjustments to their apps to ensure a smooth transition. Thank you for your understanding and cooperation.
The previous announcement for Project/Fields Association Improvements for team-managed projects has been updated to clarify that all fields are affected by the change and not just user-created custom fields.
Re-read the announcement by visiting https://developer.atlassian.com/changelog/#CHANGE-2278
Internationalization (i18n) for Forge apps is now generally available. This allows you to add translation support to your app so that it can adapt based on a user’s language and locale.
In addition to the Confluence and Jira modules that were supported during the EAP, internationalization support can now also be added to Bitbucket, Compass, and Jira Service Management modules, as well as Forge resolvers.
For more information, see Internationalization.
Rate this page: