Changelog

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.

We’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):

• Issue Action

• Issue Activity

• Issue Panel

• Issue Context

• Custom Field

• Custom Field Type

• JQL Function

• Entity Property

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.

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.

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.

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.

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.

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:

1. Create the work type using the Create work type API

2. 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).

• 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.