This page contains announcements and updates for developers from various products, platforms, and programs across Atlassian. It includes filter controls to make it easier to only see updates relevant to you.
To ensure you don’t miss any updates, we also provide RSS feeds. These feeds will take on any filters you applied to the page, and are a standardized way of keeping up-to-date with Atlassian changes for developers. For example, in Slack with the RSS app installed, you can type /feed <FEED URL> in any channel, and RSS updates will appear in that channel as they are posted.
SSH access to Bitbucket Cloud repositories via bitbucket.org will be removed after approximately six months. SSH traffic is being separated from HTTPS traffic to enable enhanced security protections on Bitbucket's public web and API endpoints.
Customers who use Git over SSH must update their remote URLs to use ssh.bitbucket.org instead of bitbucket.org. HTTPS access to bitbucket.org is not affected by this change.
What is changing
Bitbucket Cloud is splitting HTTPS and SSH traffic so that bitbucket.org will serve only HTTPS requests. All SSH-based Git operations (clone, push, pull, fetch) must use the new ssh.bitbucket.org hostname.
Migration steps
For each repository using an SSH remote, update the remote URL:
1
git remote set-url origin [email protected]:<workspace>/<repo>.gitOn first connection to ssh.bitbucket.org, verify and accept the new host key when prompted, or pre-add it to ~/.ssh/known_hosts.
Update any CI/CD pipelines, deployment scripts, or automation that use SSH to clone or push to bitbucket.org.
If your network restricts outbound SSH connections via firewall rules, ensure ssh.bitbucket.org on port 22 is allowlisted.
More details are captured in this community blogpost.
Timeline
Customers will have approximately six months from the announcement date to complete the migration. After the migration period ends, SSH connections to bitbucket.org will be refused.
To maintain system stability as our usage scales, we updated Bitbucket Pipelines to only detect the [skip ci] or [ci skip] label within the first 200 characters of a commit message. This means pipelines won’t be skipped if the label appears further in a long message.
To ensure your builds are intentionally skipped, place the label near the start of your commit message, ideally in the subject line. Manual runs are not affected by this change.
For details, read
https://support.atlassian.com/bitbucket-cloud/kb/how-to-skip-triggering-an-automatic-pipeline-build-using-skip-ci-label/.
You can now migrate a Connect Jira Issue Field module to Forge's Custom Field module. The functionality is now available for Text (text) and Rich Text (rich_text) fields.
See https://developer.atlassian.com/platform/adopting-forge-from-connect/migrate-jira-issue-fields/#text-and-rich-text-fields for more details.
The boolean usages of the autoFocus prop have now been removed from @atlaskit/modal-dialog. The previously default value of true, which automatically moves focus to the first interactive element within the modal, is now the default with no option to set it to false. This is to improve accessibility and follow the WCAG guidelines for focus within a modal dialog.
Boolean usages of autoFocus can be removed by running the included codemod.
EDITED 8 May 2026
Hello Marketplace partners,
We're excited to share that the newest improvements to Atlassian’s design language is here, as you may have seen at Team '26!
Tile & Object system
Spotlight component
Shape – Border & Radius foundations
Labelling system (for status and categorisation)
Motion foundations
These build upon on our refreshed visual language that launched last year at Team ’25 (including colour, typography, and iconography that many of you already adopted). It makes it even easier to build modern UI that is cohesive across Atlassian and Marketplace apps, with better visual clarity and accessibility.
We will be shipping these improvements to components, design tokens and guidance as part of the Atlassian Design System (ADS), and Forge UI Kit will also receive updates.
The following are in development behind feature gates. To preview the new improvements, please see Atlassian Design System documentation. We will share adoption and migration details once they are ready for use in your apps.
The Tile & Object system replaces inconsistent custom tile-like UI elements — previously scattered across products with mismatched sizes, radii, colours, and naming conventions. We now offer a single, coherent standard for representing tasks, pages, objects, and app icons.
Changes are coming to Avatar, Icon tile, Tile and Object packages to align with the new Tile system. The Icon-object package has been deprecated and replaced by Object.
Before/After of Tile System in Jira
We are introducing a modernised onboarding component for product tours and user engagement flows consistent with our improved design language. The new Spotlight replaces the deprecated Onboarding component.
Before: Onboarding Component
After: Spotlight Component
New design tokens for border widths and corner radii bring consistency to the shape language across Atlassian UI. Atlassian Design System components will be updated as well as the @atlaskit/tokens package.
Together, these foundations ensure components feel more unified and polished — rounded corners and border styles will follow a consistent system rather than being defined ad-hoc per component. For more information on whats to come, check out our border width and radius docs.
New radius tokens
New border width tokens
We’re introducing a more intuitive, accessible, and scalable labelling system that standardises consistent presentation of statuses and categorisation, supporting app-specific needs while maintaining coherence and visual clarity.
We’ve updated the visual appearance of Lozenges, Tags, and Badges to have the right level of prominence in the UI, and look and feel harmonious in every context they show up. Lozenges can now included a trailing metric, and we are introducing a new Lozenge dropdown variant, as well as a new Avatar tag to represent individuals, teams, or AI agents.
Additionally, to provide greater visual distinction and hierarchy between Lozenge and Tag, subtle Lozenge will be deprecated and need to be migrated to the new default Lozenge appearance, or where applicable to Tag instead.
Updated components: Badge, Lozenge, ad Tag
New components: Lozenge Dropdown and Avatar tag
Motion breathes life into every interaction and brand moment within apps, helping users understand spatial relationships, confirms their actions, and carries branded human expression across experiences. Our approach to motion introduces a systematic, shared language, enabling you to make good motion the easy default, not an exception.
In the initial release, we will be introducing semantic motion tokens and base tokens as the foundation of the system. Uplifted and new motion in key Atlassian Design System components are coming, as well as an improved motion primitive to replace legacy entering components and simplify applying entry and exit transitions in UI.
Learn more about how we think about motion on atlassian.design.
Motion package before vs after
We'd love to hear from you — please share on the Atlassian Developer Community!
The nodejs20.x runtime for Forge apps has reached the end of its deprecation period and is no longer supported.
Starting May 6, 2026, Atlassian will progressively block the ability to deploy or update apps using the nodejs20.x runtime. Existing deployments will continue to function, but they are provided "as-is" without support or warranties. Over time, apps using unsupported runtimes may become non-functional or vulnerable to security issues.
You must update your app's to a supported Node.js runtime (nodejs22.x or higher) to continue deploying updates.
Edit your app’s manifest.yml file
Update the app.runtime.name property to nodejs22.x or nodejs24.x
Update your local development environment to a supported Node runtime
Update your Forge CLI to the latest version
Run npm install to update your dependencies
Test your app for compatibility with any breaking changes in the Node runtime
Deploy your app to production using forge deploy -e production
For detailed instructions, see the Node.js runtime documentation.
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/
We’ve updated Forge app upgrade behaviour for apps that add the storage:app scope to their manifest, including apps migrating from Connect to Forge.
Previously, some app versions that added storage:app could be rolled out using bulk upgrade. This behaviour changed on April 30, and is currently not supported. When a new app version adds storage:app, the upgrade requires site admin approval and can't be applied through bulk upgrade.
This behaviour applies when a new app version adds storage:app to the Forge manifest. It may affect apps adopting Forge-hosted storage, including apps migrating from Connect to Forge.
If your app already has storage:app in its manifest, this change does not affect upgrades that do not add new privileged scopes.
If you plan to add storage:app:
release the change as a major version upgrade
expect site admins to approve the new version
for now - don't rely on bulk upgrade to move existing installations to that version
consider how you will support customers who remain on the previous version until they approve the upgrade.
What’s Next
Atlassian is actively investigating restoring storage:app as a scope increase that is able to be managed by bulk upgrade
We are enhancing the partner experience in completing the Marketplace App onboarding security requirements by consolidating all security questionnaires, including both partner and app-specific questions, into a single Forge app. This app is accessible via your Marketplace App Approval requests. You can view your up-to-date questionnaire responses within your existing and future app approval requests. We are also making it easy for you to review the security scanner findings (vulnerabilities) and designate a point of contact for app-specific questions.
Please refer to the QRG for more details: https://atlassianpartners.atlassian.net/wiki/spaces/resources/pages/1723105354/Completing+Marketplace+App+Onboarding+Security+Requirements+-+Quick+Reference+Guide
Old experience | New experience |
|---|---|
Old UI
| New UI
|
Questionnaire responses import is not available | Import feature Atlassian can perform bulk responses import on request. Questionnaire submission still require at individual app level. |
Vulnerabilities details only available for security contacts
| App vulnerabilities quick overview
|
No questionnaire completion progress bar
| Questionnaire completion count
|
Current submission history | New audit log
|
App level contacts unavailable | Designate contacts for app-specific escalations and concession/discount approvals
|
The ability to build a custom Teamwork Graph connector using Forge is now in GA. Connectors allow your app to ingest data from external tools into the Graph, associate it with Atlassian objects (for example, work items), and make the data available to customers in platform experiences like Chat, Search and Agents.
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.
What’s changing
We’ve introduced a new Bitbucket REST API endpoint that allows a Forge app to retrieve the clientKey of its linked Connect app installation.
This endpoint supports the migration process from Connect to Forge. By retrieving the clientKey, the installed Forge app can identify the equivalent Connect app installation, enabling you to perform data migration or cleanup tasks effectively.
What you need to do
To use this endpoint, ensure you have configured the linkage between your Connect and Forge apps.
Add the forgeAppId key to your Connect app descriptor.
Use the new endpoint to fetch the clientKey during your app's migration logic.
See https://developer.atlassian.com/cloud/bitbucket/link-connect-to-its-equivalent-forge-app/ on how to configure your Connect → Forge app linkage.
We are deprecating the Bitbucket Cloud legacy code search API endpoints effective May 1, 2026, with full removal on November 1, 2026.
The following endpoints are being decommissioned and will be removed on November 1, 2026:
GET /2.0/repositories/{workspace}/{repo_slug}/search/code — Repository-level code search
GET /2.0/workspaces/{workspace}/search/code — Workspace-level code search
We are actively working on the new API which will be released ahead of the removal.
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
Rate this page: