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 Software 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.
Forge apps using the UI Modifications API configured for Issue View will now have their modifications applied when issues are opened via ViewIssueModal (for example, from global pages, admin pages, or custom UI panels).
Previously, UI Modifications were not loaded silently in this context. This applies to all supported project types, and requires no changes to your app's manifest or code
For more details, see the Jira UI modifications documentation.
As recently announced in Raising the bar on Marketplace cloud app security: together we are updating the Marketplace Security Bug Fix Policy to shorten vulnerability remediation timelines for Marketplace cloud apps. These changes ensure a higher security standard across our ecosystem.
What’s changing
The remediation Service Level Objectives (SLOs) for Marketplace cloud apps are being shortened. The timelines for Data Center apps remain unchanged.
Updated Cloud App SLOs (Enforceable September 1, 2026):
Critical: 10 days
High: 4 weeks
Medium: 12 weeks
Low: 25 weeks
Data Center App SLOs (Unchanged):
Critical: 12 weeks
High: 12 weeks
Medium: 12 weeks
Low: 25 weeks
Additionally, we have published the Marketplace Security Enforcement Policy, a consolidated source of truth for marketplace security compliance expectations, including vulnerability management, OAuth compliance, partner verification, bug bounty participation, and incident response.
What you need to do
Review the new timelines: Ensure your internal processes are updated to meet the new cloud app SLOs by September 1, 2026.
Check your tickets: We have corrected an issue where some AMS Data Center tickets incorrectly showed cloud remediation dates. If you believe a ticket still has an incorrect date, please raise an ECOHELP ticket.
Watch the policy page: The Marketplace Security Enforcement Policy is a living document, we recommend "watching" the page for future updates.
We've introduced the Tile component for Forge UI Kit apps, now available in Preview. The Tile component is a rounded square container for displaying assets like emojis, or objects in a consistent, styled way.
The component supports various sizes (from 16px to 48px), customizable background colors using design tokens, optional borders, and adjustable internal padding for different asset types including third-party logos.
For implementation details and examples, see the Tile component documentation.
The jira:actionValidator module (Preview) now supports the workItemTypeChanged action across multiple flows, enabling custom validation whenever a user changes a work item's type. The validator is triggered in:
Issue view - the user changes the work item type from the type field on the issue view.
Move issue - when the work item type changes as part of moving an issue.
Bulk move/migrate - the work item type changes as part of a bulk move or migration.
Convert to subtask - when a standard work item is converted to a subtask type.
Convert subtask to a work item - when a subtask is converted to a standard work item.
Also, a new context variable newIssueTypeData (type: IssueType) has been onboarded alongside the existing newIssueType (type: String, returns the issue type ID), allowing more refined conditions on the target work item type within your Jira expression.
Read more here - https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-action-validator/#workitemtypechanged
Forge custom fields can no longer be edited through the legacy bulk edit wizard (/secure/views/bulkedit/BulkEditDetails.jspa). On the legacy screen, they now appear under Unavailable actions with a redirect message.
Forge custom fields remain fully supported in the new bulk edit experience, available from the list view, backlog view, and JQL search page.
For details on the new bulk edit experience, see https://support.atlassian.com/jira-software-cloud/docs/edit-multiple-issues/ (refer to the Edit fields in multiple work items from the list section).
We are announcing the deprecation of https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-issue-glance/ (jira:issueGlance), as we have replaced with https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-issue-context/ (jira:issueContext) module. The Jira Issue Glance module will soon be removed from the work items completely.
Please refer to the following documentation for more details - https://developer.atlassian.com/cloud/jira/platform/future-proof-issue-glance-implementation/
Following Forge modules - jira:customField, jira:customFieldType and jira:issuePanel can now run for unlicensed and anonymous users in Jira and Jira Service Management. This means your apps will work on publicly accessible pages and for users who don't have a full Jira and JSM license.
By default, Forge apps only run for licensed Jira and JSM users. To allow your app to serve unlicensed and anonymous users, add the unlicensedAccess property to your modules in manifest.yml.
Please refer to following guide for more details - https://developer.atlassian.com/platform/forge/access-to-forge-apps-for-unlicensed-users/#introduction.
We're deprecating the following Jira Software Cloud REST endpoints that use random page access:
GET /rest/agile/1.0/board/{boardId}/issue - Get issues for board
GET /rest/agile/1.0/board/{boardId}/backlog - Get issues for backlog
GET /rest/agile/1.0/board/{boardId}/epic/{epicId}/issue - Get board issues for epic
GET /rest/agile/1.0/board/{boardId}/epic/none/issue - Get issues without epic for board
GET /rest/agile/1.0/board/{boardId}/sprint/{sprintId}/issue - Get board issues for sprint
GET /rest/agile/1.0/epic/{epicIdOrKey}/issue - Get issues for epic
GET /rest/agile/1.0/epic/none/issue - Get issues without epic
GET /rest/agile/1.0/sprint/{sprintId}/issue - Get issues for sprint
There is a deprecation period of 6 months, and these endpoints will be removed after November 1, 2026.
Over the years, Jira has grown its customer base, and people are using Jira at larger scale and in more complex ways. This led us to make similar changes in the deprecation of JQL search and Evaluate expression endpoints previously to make issue searches more reliable, performant, and scalable. Since the Jira Software APIs mentioned are built on JQL search, we are introducing similar changes to make these operations more reliable, performant, scalable and consistent with the Jira Platform JQL Search API.
To migrate your integrations, you should switch to the new replacement endpoints which use token based pagination.
For a list of replacement endpoints, and other information, see More details below.
Here is a list of recommended replacements.
Deprecated Endpoint | New Endpoint |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We have tried to make the new endpoints as compatible as possible with the previous ones, however there are some breaking changes:
We’ll replace random page access with a continuation token API. You may already be familiar with this pattern from the JQL Search API. This means you won't be able to get multiple pages at the same time with parallel threads. The startAt parameter will be replaced with nextPageToken.
The total field is no longer returned in responses. If you need an issue count, use the dedicated approximate-count endpoints instead:
POST /rest/api/3/search/approximate-count- Count issues using JQL
GET /rest/software/1.0/board/{boardId}/issue/approximate-count - Get approximate issue count for board
GET /rest/software/1.0/board/{boardId}/backlog/approximate-count - Get approximate issue count for backlog
The new endpoints support a reconcileIssues parameter, which accepts a list of up to 50 issue IDs to reconcile for stronger read after write consistency. These IDs are guaranteed to be reconciled into the search results across pages, providing stronger consistency for recently modified issues. You may already be familiar with this pattern from the JQL Search API - usage of this parameter for these new endpoints is the same as described in search after write with search and reconcile.
Use the nextPageToken returned in each response to request the next page.
First request:
1
GET /rest/software/1.0/board/{boardId}/issue?maxResults=50Response:
1
2
3
4
5
{
"issues": [...],
"nextPageToken": "CAEaAggB",
"isLast": false
}Next request:
1
GET /rest/software/1.0/board/{boardId}/issue?maxResults=50&nextPageToken=CAEaAggBWhen nextPageToken is absent in the response and isLast is true, you are on the last page.
Use the approximate-count endpoints:
GET /rest/software/1.0/board/{boardId}/issue/approximate-count
GET /rest/software/1.0/board/{boardId}/backlog/approximate-count
Response:
1
{ "count": 142 }Use the approximate-count endpoints and JQL as follows:
Deprecated endpoint | Approximate count API Equivalent | JQL parameter |
|---|---|---|
|
|
e.g.
|
|
|
|
|
|
e.g.
|
|
|
e.g.
|
|
|
|
|
|
e.g.
|
Response:
1
{ "count": 142 }
Use the reconcileIssues parameter to pass up to 50 issue IDs that should be included in results. These will be reconciled into the results regardless of indexing lag. This list must remain consistent across all pages of a paginated request. See how reconcileIssues is used in search after write with search and reconcile for more details.
1
GET /rest/software/1.0/board/{boardId}/issue?reconcileIssues=10001&reconcileIssues=10002&reconcileIssues=10003We’ve introduced new "enhanced" APIs for Jira Software Cloud to improve how you list and count issues. These new endpoints offer better performance, token-based pagination, and the option for stronger consistency reads compared to existing issue listing operations.
The new issue listing APIs include:
GET /rest/agile/1.0/board/{boardId}/issue - Get issues for board (enhanced)
GET /rest/agile/1.0/board/{boardId}/backlog - Get issues for backlog (enhanced)
GET /rest/agile/1.0/board/{boardId}/epic/{epicId}/issue - Get board issues for epic (enhanced)
GET /rest/agile/1.0/board/{boardId}/epic/none/issue - Get issues without epic for board (enhanced)
GET /rest/agile/1.0/board/{boardId}/sprint/{sprintId}/issue - Get board issues for sprint (enhanced)
GET /rest/agile/1.0/epic/{epicIdOrKey}/issue - Get issues for epic (enhanced)
GET /rest/agile/1.0/epic/none/issue - Get issues without epic (enhanced)
GET /rest/agile/1.0/sprint/{sprintId}/issue - Get issues for sprint (enhanced)
To maintain high performance, these enhanced listing APIs do not return total issue counts. If you need issue counts, use these new dedicated endpoints:
GET /rest/agile/1.0/board/{boardId}/issue/approximate-count - Get approximate issue count for backlog
GET /rest/agile/1.0/board/{boardId}/backlog/approximate-count - Get approximate issue count for board
The jira:globalBackgroundScript module is now more powerful and adds following major functionality to the module -
Experience-based access control - Restrict which Jira views your script runs on using the experience property in the manifest. If no experience is specified, the script will not run anywhere.
Modal support - Open modal dialogs from a background script on any allowed view using the https://developer.atlassian.com/platform/forge/apis-reference/ui-api-bridge/modal/.
View context access - Access view-specific context such as issueKey, projectId, boardId, and project.type depending on the current Jira view.
Please read more here https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-global-background-script/.
We’ve introduced a platform-level URL persistence and redirect feature for apps migrating from Connect to Forge. Jira and Confluence will now accept legacy Connect URLs (including full path, query parameters, and fragments) and transparently redirect them to the corresponding Forge app module. For more information on how it works, please see the documentation here.
We have now added the ability to use the following as dynamic modules, available under Forge’s Early Access Program (EAP):
To start testing, sign up for the EAP here.
You can now nominate genuine migration blockers or major customer‑impact risks via the “Request review” flow on FRGE issues.
This flow will allow us to triage and assess requests to address remaining blockers to Forge migration before Connect end of support in December 2026. We’ll review requests over 3 monthly cycles, then freeze decisions.
Please review for existing tickets before creating new FRGE tickets. You may also review the announcement.
We’ll publish the outcomes of these decisions on the following pages:
Approved / available capabilities:
https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-forge-equivalences/connect-forge-capabilities-available/
Not‑available capabilities (including rejected requests):
https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-forge-equivalences/connect-forge-capabilities-notavailable/
Following this deprecation announcement on Feb 17, 2026, the Connect Inspector Service is now decommissoned.
We recommend migrating to Atlassian Forge for a more robust Events model, as Atlassian Connect will reach end of support in December 2026.
Developers who still need similar functionality can use the open‑sourced version of the tool.
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.
Rate this page: