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.
In 6 months on Feb 25, 2027, app macros will only appear in one category in the modal element browser, and the categories ([string]) property will be fully replaced by a new category (string) property for Forge app macros.
Furthermore, we’re updating both the slash menu element browser and modal element browser to improve discoverability of our shared offerings, expected to begin rollout on Oct 6, 2026.
These changes impact all apps using macros and require action. Read More details below for more information on what’s changing, action required, and timelines.
All apps using Macros. Learn more about app macros at the following links.
https://developer.atlassian.com/platform/forge/manifest-reference/modules/macro/
https://developer.atlassian.com/cloud/confluence/modules/dynamic-content-macro/
https://developer.atlassian.com/cloud/confluence/modules/static-content-macro/
categories ([string]) property will be fully replaced by a new category (string) property for Forge app macrosToday, app macros can set an optional categories ([string]) property that defines which categories (potentially multiple) the app macro should appear in within the modal element browser (not the slash menu element browser).
In 6 months on Feb 25, 2027, all app macros will only be able to appear in one category in the modal element browser instead of multiple categories like they can today, to improve end users' browsing experience.
Since we are moving toward one category per app macro to improve the browsing experience, we have introduced a new category (string) property, where developers can define one valid category string to determine where their app macro shows up in both the modal element browser and slash menu element browser. Valid category inputs for this field will be:
structure (Native examples: Action item, Table, Status)
media (Native examples: Image, video, or file, Link, Emoji)
embed (Native examples: like Google Drive, Figma, Dropbox)
text-formatting (Native examples: Bullet list, Heading 1, Quote)
data-and-charts (Native examples: Database, Jira work items, Child items)
To learn more about these new categories, read the second part of this announcement.
On Feb 25, 2027, the categories ([string]) property will no longer be recognized by Forge app macros. It will effectively be fully replaced by this new category (string) field, making it so Forge app macros only appear in one category. Make sure to update the category (string) property by then to explicitly set which category you’d like your app macro to live in. Otherwise, if there is no valid entry in the category (string) property by then, your app macro will appear in an “Other elements” category as well as the default “All” category.
On Feb 25, 2027, Connect app macros will only appear in the first category listed in their categories ([string]) property with the below mapping. Connect app macros will not gain access to the new category (string) property.
formatting, confluence content, navigation, admin → structure
reporting, development → data-and-charts
media, visuals, communication → media
external-content → embed
No valid categories provided → Other elements (as well as the default "All" category)
Before the above deprecation on Feb 25, 2027, we will also be updating the categories & appearance of the slash menu element browser and modal element browser to improve discoverability of our shared offerings, expected to begin rollout on Oct 6, 2026. We will be:
Updating the set of categories we have to better capture our shared offerings.
Updating the slash menu element browser to actually show the categories.
Updating the modal element browser to show the new categories.
Cosmetically modernizing the slash menu and modal element browser.
Example of new categories in slash menu element browser
Example of new categories in modal element browser
Before this release, the valid set of categories app macros could use were:
Formatting - formatting
Confluence content - confluence-content
Navigation - navigation
Admin - admin
Reporting - reporting
Development - development
External content - external-content
Media - media
Visuals and images - visuals
Communication - communication
After this release, the new valid set of categories app macros can use will be the following. Any of the above categories not listed below will be considered legacy categories.
Structure - structure (Native examples: Action item, Table, Status)
Media - media (Native examples: Image, video, or file, Link, Emoji)
Embed - embed (Native examples: like Google Drive, Figma, Dropbox)
Text formatting - text-formatting (Native examples: Bullet list, Heading 1, Quote)
Data and charts - data-and-charts (Native examples: Database, Jira work items, Child items)
Any app macros with legacy categories still listed in their categories property on Oct 6, 2026 will have their categories automatically mapped to new categories in product with the below mapping.
formatting, confluence content, navigation, admin → structure
reporting, development → data-and-charts
media, visuals, communication → media
external-content → embed
No valid categories provided → Other elements (as well as the default "All" category)
If, however, you would like your app macro to appear in different categories than it would automatically be mapped to, update the new aforementioned category (string) property with any one of the new categories (available only for Forge app macros) by Oct 6, 2026.
As mentioned in the first part of this announcement, app macros will continue to be able to appear in multiple categories in the modal element browser for 6 months until Feb 25, 2027 , when app macros will begin to appear in only one category.
In the slash menu element browser, however, with very limited screen real estate, app macros will only appear in one category upon release on Oct 6, 2026. Furthermore, we plan to show up to 30 items per category in the slash menu element browser. If there are more items, we’ll show a “View more” CTA that leads to the modal element browser where all items appear. However, to ensure app macro discoverability, we will always show up to 10 app macros (if they exist) in a category in addition to the 30 item maximum. In the future, we will explore more dynamic behavior here.
For Forge app macros, this category will be determined by the category (string) property if available, or the first category listed in categories ([string]) as a fallback until Feb 25, 2027, when categories ([string]) will no longer work.
For Connect app macros, this category will be determined by the first category listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.
To ensure your app macro appears in an accurate category as we roll out these changes, we strongly recommend updating the new category (string) property (available for use by developers now) with one of the new valid categories below by Oct 6, 2026, when we begin to rollout the modernized element browser experience.
If not by Oct 6, 2026, be sure to update the new category (string) property by Feb 25, 2027 to ensure your app is assigned a category when categories [(string)] is no longer recognized. Otherwise, it will be shown in “Other elements” as well as the default “All” category.
Valid categories:
Structure - structure (Native examples: Action item, Table, Status)
Media - media (Native examples: Image, video, or file, Link, Emoji)
Embed - embed (Native examples: like Google Drive, Figma, Dropbox)
Text formatting - text-formatting (Native examples: Bullet list, Heading 1, Quote)
Data and charts - data-and-charts (Native examples: Database, Jira work items, Child items)
To help developers plan, here is a simplified timeline of the upcoming changes.
Between now and Oct 6, 2026:
In the slash element browser: All app macros will continue to appear as they do today.
In the modal element browser: All app macros will continue to appear in the macro element browser in any valid legacy categories listed in categories ([string]). The new category (string) property will not be used in product until then.
On and after Oct 6, 2026, and before Feb 25, 2027:
Forge app macros will:
In the slash element browser: Appear only in one category determined by the category (string) property – or, the first category listed in categories ([string]) as a fallback if no valid category (string) is set.
In the modal element browser: Appear either in one category determined by the category (string) property – OR in one or multiple categories listed in categories ([string]) as a fallback (with above mapping between legacy and new categories) if no valid category (string) is set.
Connect app macros will:
In the slash element browser: Appear only in one category determined by the first category listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.
In the modal element browser: Appear in one or multiple categories listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.
On and after Feb 25, 2027:
Forge app macros will:
In the slash element browser: Appear only in one category determined by the category (string) property. categories ([string])will no longer work or be recognized.
In the modal element browser: Appear only in one category determined by the category (string) property. categories ([string])will no longer work or be recognized.
Connect app macros will:
In the slash element browser: Appear only in one category determined by the first category listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.
In the modal element browser: Appear only in one category determined by the first category listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.
We highly recommend moving to Forge and following the above steps for Forge apps. Otherwise, no work is required for Connect apps, as Connect app macros will not gain access to the new category (string) property nor be able to update their categories ([string]) property.
Lastly, thank you for giving valuable feedback on RFC-140: Updating categories in the editor’s element browser about this topic.
We’re reverting the change announced in CHANGE-3388 due to technical challenges with the data.
The maintenance period shown on refund (credit note) rows in Marketplace reporting will return to the previous behavior while we address these challenges.
The correction that expanded refund maintenance periods to reflect the full term across all constituent invoice lines is being reverted and old behaviour is being restored prior to CHANGE-3388
Refund amounts are unchanged. As it only updated the reported period dates; no monetary values are affected.
The majority of refund rows, approximately 86%, were already displaying the correct period and will still be unimpacted.
Review your reporting. If you use maintenance period dates from Marketplace reports to calculate period-based metrics, such as annualized revenue or daily run-rate, you may see changes for reverted refund rows.
No action is required if you only use refund amounts in your reporting, because those values remain unchanged.
We’ll provide a further update when the correction is ready to be reintroduced.
The Rovo Agent Connector is now officially in Preview. You can now deploy apps using this module to production and staging environments, enabling Marketplace listing.
What's changing
A2A v1.0 is now required — v0.3 is no longer supported. Apps still on v0.3 will be rejected at deployment. See the migration guide for full details.
System user mentionability — adding rovo:agentConnector to your app makes the system user non-mentionable; the agent connector user takes its place. The CLI (v13.3+) warns and prompts for approval at deploy time.
What you need to do
Add version: "1.0" to protocols.agent2Agent in your manifest.
Update your JSON-RPC implementation to the A2A v1.0 protocol — see the migration guide.
Update to Forge CLI v13.3+ (npm install -g @forge/cli@latest).
For full integration details, see https://developer.atlassian.com/platform/forge/remote-agents-in-jira/ and the https://developer.atlassian.com/platform/forge/manifest-reference/modules/rovo-agent-connector/.
This deprecation was originally announced in 2022, and we are proceeding with the removal of the merge parameter now. More information including about alternative solutions for merge conflict retrieval can be found in our community post about this change. This capability will be removed as of September 4th, 2026.
You can now use the Forge CLI to provision a demo development site and install your app directly to it. A demo development site is a One Atlassian environment containing realistic seeded data and enterprise editions of Jira, Confluence, Jira Service Management, and Rovo.
You can provision or retrieve your active demo development site by running:
1
forge site provisionIf you already have an active demo site, the CLI returns it instead of provisioning another one. Otherwise, the CLI requests a new site and displays its provisioning status.
You can also deploy and install your app directly to your demo site:
1
2
forge deploy
forge install --demo-siteThe short form of --demo-site is -d:
1
forge install -dIf you don’t have an active demo site when running forge install --demo-site, the CLI offers to provision one before continuing with the standard installation flow.
Key details include:
Site allocation: Each developer can have one active demo development site. You can use the same site to develop and test multiple Forge apps.
Site lifecycle: Demo sites are active for 90 days by default.
Background provisioning: You can press Ctrl+C while waiting without cancelling the provisioning request. Run forge site provision again later to check its status.
Installation options: You can’t combine --demo-site with --site. Existing forge install and forge install --site <site> workflows continue to support traditional Atlassian development sites.
Update to the latest version of the Forge CLI:
1
npm install -g @forge/cli@latestNo action is required if you want to continue using an existing Atlassian development site.
To use a Forge demo development site, either provision one first with forge site provision or run forge install --demo-site after deploying your app.
For more information, see:
Deprecation Notice
We’ve updated Marketplace partner listing API responses so that emergency support contact details are returned only to callers who are authorised to manage partner details. Unauthorised or anonymous callers will no longer receive the emergency contact field field in listing support contact data.
This change aligns listing access with the current Marketplace roles and permissions model and is an important security measure. Integrations consuming listing support contact data should not assume that the ‘emergency contact' field is always present and should handle missing values accordingly.
This update applies to existing listing read flows only. It does not introduce new endpoints. Other non-sensitive support fields continue to be returned as before.
As was announced in our Community blog deprecation of native Bitbucket Cloud Issues and Wikis, and API change log the API endpoints that support Issue Tracker are now fully removed.
What's changing
With Forge CLI 13.4.0 you can now configure the Forge CLI to use a network proxy natively through CLI settings or environment variables. This removes the need for manual workarounds, such as modifying the CLI source code or using the global-agent package.
To save a proxy configuration for all Forge CLI commands, run:
1
forge settings set proxy ${yourProxyServer}Alternatively, you can configure the proxy for your current terminal session by setting the FORGE_PROXY environment variable:
1
export FORGE_PROXY=${yourProxyServer}Update to the latest version of the Forge CLI by running npm install -g @forge/cli.
Configure your proxy using the forge settings command or the FORGE_PROXY environment variable as shown above.
For more information on using Forge in restricted network environments, see Using the Forge CLI on a corporate network.
As per our previous announcement, we will be progressing admin-facing migration messaging for apps that have declared a migration intent of ‘yes’ on the Connected Apps page from the Developer Canary Program to production instances. This rollout will begin in approximately two weeks.
Apps that have declared connectToForgeMigration with a migration intent of "yes"
The following app categories have already been rolled out to receive admin-facing messaging as per our previous changelog:
Apps that have declared connectToForgeMigration with a migration intent of "no"
Apps that have declared connectToForgeMigration with a migration intent of "unsure"
Apps that have not adopted the connectToForgeMigration module
Apps without a Forge manifest (i.e., Connect apps)
Adopt the connectToForgeMigration module in your Forge manifest for each major version of your app (https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-to-forge-migration-module/).
Declare your migration intent as this determines which cohort your app falls into and when messaging appears.
Provide a migration URL. This URL will be surfaced directly in customer-facing notices, replacing the default Atlassian messaging with your app-specific guidance.
Preview the experience now using the Developer Canary Program. Customer messaging is already live on canary tenants for apps that have declared ‘yes’ to the migration intent. Install your app on a canary instance, navigate to the Connected Apps page, and confirm your migration URL renders as expected before the production rollout reaches your cohort.
Exemptions
Apps that are blocked by an accepted Connect EOS FRGE ticket will be exempt from customer messaging until one month past the delivery date of the blocking feature. This exemption list is determined exclusively by partners who have submitted a Connect EOS Submission request on these accepted tickets, providing a valid use case and explanation. If an app utilises an affected feature but has not submitted a Connect EOS submission, it will not be exempted from this messaging.
For the full customer-facing experience (including more information on what admins will see), please visit the documentation here. This page will also be shortly updated to capture our rollout approach.
Bitbucket has added support for bearer authentication for API tokens.
What’s changing:
Bitbucket Cloud has added support for Bearer authentication when using API tokens. You can now authenticate your API requests by sending the token in a Bearer authorization header, providing a more standard and secure alternative to Basic authentication.
1
2
3
4
curl --request POST \
--url 'https://api.bitbucket.org/2.0/repositories/{workspace}/{repository}/commits' \
--header "Authorization: Bearer {api_token}" \
--header 'Accept: application/json'What you need to do:
No action is required. Bitbucket Cloud continues to support both Basic and Bearer authentication for API tokens. If you have existing integrations using Basic authentication, they will continue to work without modification.
For more information on creating and using tokens, see the API tokens documentation.
Following the initial Point-to-Point Logs Export EAP announcement, the feature now includes the following improvements:
What's changing
Environment filtering: You can now filter which environments (production, staging, or development) send logs to your third-party logging tool. This helps you manage costs by, for example, exporting only production logs while using the Forge Developer Console for other environments.
Per-app export URLs: You can now configure unique export URLs for different sets of apps within your developer space. This gives teams with multiple apps the flexibility to route logs to separate destinations.
Google Cloud Logging support: You can now export Forge app logs directly to Google Cloud Logging, in addition to existing support for Datadog, Sumo Logic, Amazon CloudWatch, and Splunk.
What you need to do
If you haven't already, sign up for the EAP.
Review the setup guide to understand how to configure your observability vendor and share the required details in the EAP form.
To address a longstanding feature request, the Bitbucket design team is researching how you stay informed about activity across the repos and projects you work with. We'd love to hear directly from you to help us understand whether and how an activity feed in Data Center could be valuable. Sign up here
What's involved?
A 60-minute Zoom conversation
Responses kept confidential within Atlassian and used only to inform our research
$100 e-gift card compensation for your time
You're a great fit if you:
Use Bitbucket Data Center or Cloud regularly as part of your workflow
Work across multiple repositories or projects day-to-day
Are part of an engineering team at an enterprise organization
What's changing
The Forge CLI build and deploy commands now include a new --inspect option. This option copies the Forge application bundle, as packaged for Atlassian infrastructure, into your local .forge/inspect directory.
You can use this to:
Investigate the final structure of your application before it is deployed.
Troubleshoot bundling issues or unexpected behavior in the deployed app.
This new option replaces the undocumented FORGE_INSPECT_ARCHIVE environment variable, which is now deprecated and will no longer function.
What you need to do
To inspect your application bundle, run either of the following commands:
forge build --inspect
forge deploy --inspect
After the command completes, you can find the packaged application files in the .forge/inspect directory within your project.
See the https://developer.atlassian.com/platform/forge/cli-reference/build/ and https://developer.atlassian.com/platform/forge/cli-reference/deploy/ documentation for more information.
Forge CLI 13.3.0 introduced a server-side manifest check as part of the new approval workflow. However, environment variables in the manifest.yml file were not being interpolated before being sent to the validation endpoint. This caused the linter to return false-positive MANIFEST_INVALID_RULE errors for valid manifests.
This issue is fixed in Forge CLI 13.4.0. The CLI now correctly interpolates environment variables before performing the pre-deployment manifest check.
Update your Forge CLI to version 13.4.0 or later by running:
1
npm install -g @forge/cli@latestFor more information on using variables in your manifest, see the manifest variables reference.
To learn more about why these manifest checks and approvals are required, see the documentation on major version upgrades.
You can now use UI modifications in the Jira Service Management (JSM) agent view. This is an extension of the existing jira:uiModifications module and covers the views your agents use inside a service project.
What's changing
UI modifications now support three specific agent views:
Global issue create (GIC) - viewType: GICAgentView
Issue view - viewType: IssueViewAgentView
Issue transition - viewType: IssueTransitionAgentView
The agent view supports the same fields and methods as equivalent Jira views but is tailored for service projects.
Key differences include:
Extension context: Exposes the requestTypeId of the work item.
Supported fields: The set of supported fields differs from the JSM request create portal view.
REST API: The UI modifications REST API (GET, POST, and PUT) now accepts these three agent view types. When configuring agent view contexts, portalId must not be set, and requestTypeId is optional (omitting it means the context is not scoped to a specific request type). One of projectId, issueTypeId, or viewType can act as a wildcard, with a maximum of one wildcard per context.
You can use view.getContext() to detect the current view type:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import { view } from '@forge/bridge';
import { uiModificationsApi } from '@forge/jira-bridge';
uiModificationsApi.onInit(async ({ api }) => {
const context = await view.getContext();
switch (context.extension.viewType) {
case 'GICAgentView':
// Runs when an agent creates a work item in a service project.
break;
case 'IssueViewAgentView':
// Runs when an agent opens a work item in a service project.
break;
case 'IssueTransitionAgentView':
// Runs when an agent transitions a work item in a service project.
break;
default:
break;
}
}, () => []);No action is needed if you don't want to support the agent view. If you do want to add agent view support, simply define the context for the Agent View view types using the REST APIs – your Forge app will then be invoked automatically in the agent-specific views.
For more information, see:
• JSM UI modifications module documentation (to be attached)
• uiModifications API bridge (to be attached)
Rate this page: