Atlassian developer changelog

Starting February 1, 2027, we'll progressively roll out a change to the portfolioChildIssuesOf() JQL function so its results include work items in team-managed spaces. Today, the function only follows hierarchy in company-managed spaces, so searches can miss descendants that live in team-managed spaces.

• portfolioChildIssuesOf() will return descendants through valid team-managed space hierarchies, including supported relationships between company-managed and team-managed spaces, such as a team-managed epic under a company-managed initiative.

• Queries that use NOT IN portfolioChildIssuesOf() will exclude these additional work items.

• Results continue to respect hierarchy rules, user permissions and issue security.

• REST API request and response formats don't change.

If your app, saved filters or automation rules assume that team-managed work items are excluded from portfolioChildIssuesOf() results:

1. Find the queries that use portfolioChildIssuesOf().

2. Check whether team-managed work items in the results would affect your logic.

3. If they would, update your queries or result handling before February 1, 2027.

We'll publish another update when the rollout starts.

What's changing
We've updated the minimum compatible Node.js version for the Forge CLI. The CLI now requires Node.js 22.23.4, 24.22.1, 26.12.1, or newer.

Node.js 20 has reached end of life and is no longer supported. To continue using the Forge CLI to develop and deploy your apps, you must upgrade your local development environment to one of the supported versions listed above.

What you need to do

1. Check your current Node.js version by running node -v in your terminal.

2. If you are running a version older than the requirements, download and install a supported version from the Node.js website.

3. Update your Forge CLI to the latest version by running:npm install -g @forge/cli@latest

4. Verify the installation by running forge --version.

For more information on setting up your development environment, see the Getting started guide.

Following the previous deprecation announcement, we will begin scheduled brownouts of the Bitbucket Cloud Code Search API on 3 November 2026 at 00:00 UTC.

Brownouts are temporary periods when the API is unavailable, intended to help you identify integrations that still need to migrate. The brownout duration will progressively increase before the API becomes permanently unavailable on 15 November 2026 at 00:00 UTC.

Migrate your integrations to the workspace code search API before the brownouts begin.

I18n.getText() calls are now translated when their method namespace is a function invocation immediately followed by .I18n.getText(...). This covers inlined module loads and ES-module interop getters emitted by webpack and rspack in both development and production builds.

Previously these phrases could fall back to the untranslated key at runtime, and some unminified bundles could be left syntactically invalid.

When using webpack or rspack, prefer an ES module import:

The following form is still not supported:

• CommonJS destructuring that produces a bare I18n.getText(...) call, because WRM requires a namespace before .I18n.getText(...):

See https://developer.atlassian.com/server/framework/atlassian-sdk/internationalising-your-plugin-javascript/#supported-method-namespaces for more information

A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-152-increasing-maximum-memory-for-forge-functions/103441

As previously announced, the jira:fullPage and confluence:fullPage modules have been removed on 30 September 2026 in favor of the unified global:fullPage module.

What’s changing

• The product-specific jira:fullPage and confluence:fullPage modules are no longer supported in the Forge manifest.

• Requests routed to legacy URLs will automatically forward to the corresponding global:fullPage URL.

• Users accessing legacy paths will see a prompt to update their bookmarks.

• Automatic forwarding support will be maintained until December 18, 2026.

If you haven’t already migrated your apps, refer to global:fullPage documentation to get started: https://developer.atlassian.com/platform/forge/manifest-reference/modules/global-full-page/

The Atlassian Rovo MCP Server is adding twelve Jira Service Management tools through MCP V2. These tools support searching and triaging requests, reviewing and approving Request Resolver plans, creating customer requests, transitioning requests, deciding pending approvals, and reading or setting Workforce Management agent availability.

The four existing Operations tools getJsmOpsAlerts, getJsmOpsScheduleInfo, getJsmOpsTeamInfo, and updateJsmOpsAlertare also moving from MCP V1 to MCP V2. They retain their existing names and are not counted as new tools.

JSM tools in MCP V2 support OAuth 2.1 and API token authentication. Read tools belong to read_jsm and require read:jsm:agent-interface; write tools belong to write_jsm and require write:jsm:agent-interface. getJsmRequestResolverPlans, searchJsmRequests, and approveJsmRequestResolverPlans also require read_jira and read:jira:agent-interface. updateJsmOpsAlert additionally requires read:jsm:agent-interface.

Tool availability depends on granted scopes, the permission groups enabled by your organization admin, and your app access. See Supported tools for details.

What's changing
From January 1, 2027, Atlassian cloud will add new IP address ranges as we expand our cloud infrastructure.

The new ranges are in addition to our existing ones.

The new ranges are:

• New range: 131.162.88.0/21

  • Requests to Atlassian (browsers and your clients calling Atlassian APIs): 131.162.88.0/23

  • Requests from Atlassian (webhooks, Connect lifecycle calls, and other requests from Atlassian to your app): 131.162.90.0/23

What you need to do
If your app, remote backend, or integration allowlists Atlassian IP addresses, you must add these ranges before January 1, 2027, to avoid service interruptions.

These ranges are already included in our official IP range list (viewer tool). If you automate your allowlist updates from this file, no further action is required. For more details, see our documentation on IP addresses and domains for Atlassian cloud apps.

EARLY ACCESS: Forge Global Apps
We are ready to kick off the Forge Global Apps Early Access Program (EAP). Forge Global Apps are installed in the platform and can optionally link to one or more Atlassian apps.

What's changing

• Installation into unit instead of an Atlassian app workspace

• Apps can work across sites in a unit

• No required Atlassian app link

What you need to do
Sign up for the EAP: submit a request https://ecosystem.atlassian.net/servicedesk/customer/portal/1040/create/18611 and we will get in touch with instructions soon

The Teamwork Graph Consumption API is now moving into Preview, providing relationship-first querying across Atlassian Cloud objects and connected third-party tools.

What's changing

The Teamwork Graph API lets you query connected context across Jira work items, Confluence content, Loom videos and meetings, external development artifacts, Goals, and Teams using a unified GraphQL endpoint.

What's changing
We've introduced new experimental REST APIs for managing space policies in Jira Cloud. Space policies allow site administrators to govern the creation and usage of fields and statuses in team-managed spaces, helping to prevent configuration sprawl and maintain instance health.

The following experimental endpoints are now available:

Viewing policies

• GET /rest/api/3/policies — Get all policies

• GET /rest/api/3/policies/project/{projectIdOrKey} — Get project policy state

• GET /rest/api/3/policies/project/{projectIdOrKey}/rules — Get project policy rules

Applying policies to projects

• POST /rest/api/3/policies/{policyId}/apply — Apply a policy to projects

• POST /rest/api/3/policies/{policyId}/remove — Remove a policy from projects

• PUT /rest/api/3/policies/project/{projectIdOrKey}/policies — Set the policies applied to a project

• POST /rest/api/3/policies/project/{projectIdOrKey}/validate — Validate policy application to a project

What you need to do

1. Review the Jira Cloud space policy API documentation to understand the available methods and data structures.

2. Note that these APIs are currently experimental and may change without notice.

3. If you are building integrations that create fields or statuses, ensure you handle potential blocks when a space policy is active.

What's changing
We are updating the behavior of the Confluence Cloud REST API V1 content restrictions endpoints to ensure consistency between view and edit access. Previously, it was possible for a principal (user or group) to hold an update (Can edit) restriction without holding the corresponding read (Can view) restriction on content that had view restrictions applied.

After this change, for content with view restrictions:

• All principals will hold either only the read restriction (Can view) or both the read and update restrictions (Can edit).

• If a principal holds both read and update restrictions, any API request to remove only the read restriction (but not all read restrictions) will result in a rejection.

• To move content into an "edit restricted" state for these principals, you must request the removal of all read restrictions.

What you need to do
If your application manages content restrictions via the Confluence Cloud REST API V1, review your implementation to ensure that content with view restrictions:

1. When granting update access, you also include the read restriction for that principal.

2. Your logic for removing restrictions accounts for the fact that read access is now a prerequisite for update access.

A feature to speed up app migrations that require transforming confluence macros has been added. This implements RFC-142.

See the documentation here.

What's changing
We are introducing new Confluence Cloud REST API v2 endpoints to manage content permissions and restriction states. These endpoints provide a consistent way to handle permissions across multiple content types, including pages, blog posts, databases, whiteboards, and folders.

The new endpoints are:

• GET /wiki/api/v2/{content-type}/{id}/restriction-state: Retrieves the current restriction state of the content.

• PUT /wiki/api/v2/{content-type}/{id}/restriction-state: Updates the restriction state (for example, to make content restricted or open).

• GET /wiki/api/v2/{content-type}/{id}/permissions: Lists the specific permissions (read and update) applied to the content.

• POST /wiki/api/v2/{content-type}/{id}/permissions: Adds new permissions for a user or group.

• PUT /wiki/api/v2/{content-type}/{id}/permissions: Updates existing permissions.

• DELETE /wiki/api/v2/{content-type}/{id}/permissions: Removes permissions.

What you need to do
If you are building new integrations or migrating from the V1 content restrictions API, we recommend using these new v2 endpoints.

What's changing

On Nov 30, 2026 Git requests authenticated using OAuth2.0 via the Git Credential Manager (GCM) will be blocked for versions prior to 3.0.0. This is caused by the lack of support for rotating OAuth refresh tokens, which have recently begun being enforced for Bitbucket’s OAuth 2.0 implementation. See: https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3052. Atlassian contributed changes to the open source project to include support for the rotating refresh token model, which was bundled in the v3.0.0 release (https://github.com/git-ecosystem/git-credential-manager/releases/tag/v3.0.1)

What you need to do