This page includes release notes and updates for Confluence Cloud app developers. Use this page to keep track of upcoming changes, deprecation notices, new features, and feature updates from Confluence Cloud.
For updates about changes to the Forge platform, see the Forge changelog in the Forge documentation.
You can also ask questions and learn from other Confluence Cloud developers on the Atlassian Developer Community.
The AdfRenderer component provides a way to render a valid ADF document, using the same renderer that Atlassian uses internally to render ADF content in Confluence pages, Jira work items, and so on. See ADF renderer for the full docs.
The ADF renderer component also allows you to replace node types that are unsupported in the context of a Forge app with replacement content, or remove them entirely.
See Atlassian Document Format for information on valid nodes.
Run npm i @forge/react@latest to install the preview version of the components and try them out now.
We have now removed the UI Kit @forge/react version 9 from the Forge platform. This UI Kit version was deprecated on Aug 28, 2024.
We recommend using the latest version of UI Kit (@forge/react10).
For more information, see our deprecation policy.
We're announcing a preview of rich-text bodied macros for Forge, allowing apps to define Confluence macros with a body in their manifest.
This also allows Connect apps to migrate their rich-text bodied macros to Forge.
Get started by checking out the macro module reference, or our tutorial on using rich-text bodied macros.
Rich-text body macros let users insert rich content, like images and tables, within a macro using the Confluence editor. Apps can access and render this content within their macros. Macros using a custom editor can also provide an initial macro body on the first macro insert.
To be able to deploy these changes to your manifest, you will need the latest version of the Forge CLI. Run npm install -g @forge/cli@latest on the command line to install the latest version of @forge/cli.
To learn more about migrating Connect macros to Forge, see https://developer.atlassian.com/platform/adopting-forge-from-connect/migrate-macro/.
We’re announcing a preview of custom config editors for Forge macros, allowing you to use a UI Kit or Custom UI resource for your macro’s configuration experience.
This gives you greater control over the presentation of configuration to the user and more flexibility with the storage of configuration properties.
Get started by checking out the macro module reference, or our tutorial on adding custom macro configuration.
The custom macro configuration will be rendered in a modal overlaying the page, offering a larger canvas for more complex configuration scenarios.
Macros using a custom config editor can also provide an initial macro body on the first macro insert.
To be able to deploy these changes to your manifest, you will need the latest version of the Forge CLI. Run npm install -g @forge/cli@latest on the command line to install the latest version of @forge/cli.
We are extending the deprecation period for all endpoints noted in Deprecation of v1 Confluence Cloud API endpoints and Deprecation of v1 Confluence Cloud API Endpoints to Mar 31, 2025.
The atl.footer module was accidentally removed from some Confluence content types. This module has been restored for all Confluence content types and covers Pages, Live Pages, Databases, and Whiteboards.
We now accept bug and incident reports under a single new request type: Ecosystem Support Request. This change simplifies the process of reporting issues to our support team, so that we can handle your issue more efficiently, and ensure consistent handling for all critical issues, particularly incidents.
We’ve also detailed the scope of our Developer and Marketplace support, so you have a better understanding of supported issues and response times.
We’ve stopped injecting stylesheets for Connect apps via inline styles, in favour of loading from the Connect CDN. This affects the Theming API and dynamic content macros that supported the legacy Confluence editor.
We originally announced this 6 months ago, in line with our standard deprecation policy. It is now live for https://developer.atlassian.com/cloud/confluence/developer-canary-program tenants, and will roll out to all customers widely throughout this week.
If your app doesn’t use the above Connect features, or doesn’t use a Content Security Policy (CSP) for style-src, no action is required. Otherwise, please read the details here or see https://developer.atlassian.com/platform/marketplace/security-requirements/#connect-apps on how to modify your CSP to support these changes.
To support these changes in your app, if you're using a Content Security Policy that sets the style-src policy, you must add the Connect CDN (https://connect-cdn.atl-paas.net) to your policy to allow these stylesheets to be injected. It's safe to remove unsafe-inline from your policy if you've been using it up until now.
The stylesheets mentioned here were included automatically via the Connect JS script, not manually by the app vendor. There are two circumstances under which Connect injected stylesheets into your app:
The first is only for apps which opted in to the Theming API.
The theme stylesheets previously loaded via an inline stylesheet, which forced vendors to adopt the insecure unsafe-inline policy, and is the main motivation for this change.
The second location is only for dynamic content macros.
We injected a stylesheet with CSS classes representing colors from the legacy Confluence editor.
This happened without opt-in, to be backwards-compatible with macros created in the legacy editor.
This injection was done via CSSOM, not inline styles, and therefore isn’t impacted by style-src CSP rules currently. However, it is also now being served from the CDN.
To summarise, all styles are now being loaded from the CDN, and the inline/CSSOM methods have been removed.
Starting in December, we plan to gradually rollout a change to improve how apps are organized in Confluence’s page overflow menu into an Apps item, that will help the menu scale better with more items. See More details for imagery.
No work is required from developers due to these changes. Your apps will automatically appear in the Apps item.
As discussed in an RFC, apps will be organized into an “Apps” item in the overflow menu and given a higher relative position. Accessing apps will require no additional clicks as apps will appear upon hover.
Note that apps in the overflow menu in live pages are already organized this way.
Following this deprecation notice from May 13, 2024, we're removing the POST /wiki/rest/api/content-states/delete endpoint and the GET /wiki/rest/api/content-states/task/{taskId} endpoint from the Confluence Cloud v1 REST API. They will no longer be available from the time of this announcement, and we won’t be providing a replacement functionality.
For guidance on how to adapt to these changes, see the deprecation notice.
All partners in the Developer Canary Program can now test their apps with live pages! Note that live pages are still in early access, and customers that opt in are aware that some apps may not be fully functional yet in live pages. Starting January 2025, we will start gradually rolling out the ability to opt in to the live pages beta to more customers (expecting to be available for opt in for all customers by April 2025).
To get started with testing live pages, follow the instructions here: Create and collaborate on live pages in Confluence. We also announced this in the developer community, where you can leave comments & feedback. See our community announcement here.
See More details, for more technical details & things we recommend you try.
We recommend making sure that your app works in live pages that may never be published and always remain live pages. Keep in mind that live pages can still be published (e.g. for use cases like knowledge bases), so make sure that your app still makes sense with published pages--both while viewing & editing them.
Continue to consider permissions scenarios around who can edit / view pages, these continue to exist in live pages (e.g. a user may have view-only permission of a live page).
Live pages will support the following page extension points. If you are using any other extension points, we recommend you migrate so that your app is accessible in live pages. As stated on October 31, 2024, we will be deprecating other Confluence page extension points (note that extension points beyond pages are unaffected). Learn more about the extension points we are deprecating here.
Forge
confluence:contentBylineItem
confluence:contentAction
confluence:contextMenu
Connect
system.content.action/secondary
contentBylineItem
system.content.action
system.content.action/primary
atl.general
system.content.action/modify
page.view.selection/action-panel
system.content.action/marker
atl.footer (will not render a UI component, but can still be used for running background scripts)
Bodied Macros (COMING SOON)
In December, we plan to rollout changes that make Bodied Macros like Table Filters & Aura Tabs functional in live pages. Today while editing, bodied macros only display in their “Edit” state--a text box where users can enter rich Confluence content. Users must publish to see macros in their rendered “Display” state. We will be giving users the option to switch between these “Edit” and “Display” states freely within the Editor without publishing, making them functional in Live Pages.
When inserting a bodied macro, users will see the “Edit” state of the macro by default, so they can add content. They will need to exit the “Edit” state to see the “Display” state – now, they won’t need to publish & scroll around to see the “Display” content.
When viewing a page with a bodied macro, users (assuming they did not insert the macro themselves) will see the “Display” state by default. They will be able to hover on the macro and enter the “Edit” mode.
We will let you know when we release these changes and we recommend testing your apps then to make sure they work as expected.
Non-Bodied Macros
As discussed in RFC-50, we’ve made it so non-bodied macros like Gliffy and draw.io, are more easily interacted with AND configured in the Editor, both for live pages & classic published pages. This has also been referred to as “removing the glass pane” from macros while editing. We recommend that you test your non-bodied macros in live pages to make sure they work as expected.
Since live pages do not have drafts and are not explicitly published, there are updated events for them. Note that live pages can still be published, which turns them back into standard published pages.
Webhook Key | Forge Event | Description |
|---|---|---|
|
| Emitted at the end of the first editing session of a page. The page will have a user generated title and 1 version. |
|
| Emitted at the end of every subsequent editing session. |
Currently, Live pages and draft/published pages will be differentiable via the content API by the subtype field. Currently the subtype is not available on the v2 API. This is not considered a stable API.
In the near future, we will make the subtype field available on the v2 content API, making it a stable API.
A new version is created immediately once a user makes changes, but this version will remain in flux as users make changes, and only finalized 15 minutes after the editing session ends.
Integrations that use the Create whiteboard endpoint can now benefit from two optional parameters.
Use the optional templateKey parameter to create a whiteboard with template content.
Use the optional locale parameter to specify the language of the template. If omitted, the API will use the language of caller’s user locale.
We are removing mirrors of third-party packages such as maven-central from packages.atlassian.com
We're updating how we provide packages for customers and partners to develop with our platforms. Starting February 1, 2025, we will discontinue providing third-party packages on packages.atlassian.com. Instead, customers and partners must fetch these packages directly from the original upstream repositories.
For details on how this change affects you and for guidance on migration, please refer to the documentation available at http://developer.atlassian.com .
Starting May 8, 2025, the Confluence Cloud system.content.metadata Connect extension point will no longer be available on Confluence pages.
As we bring some of our most popular extension points into the Editor to increase their visibility & make apps functional in live-edit pages, we are deprecating extension points that do not work in the Editor or are very unpopular in the Editor to simplify how customers interact with apps, and decision-making for vendors. Last week, we announced the deprecation of a number of other extension points. Learn more about other deprecated extension points here.
Developers using system.content.metadata will need to instead use different extension points that we are making available for use in the Editing experience, which will give them more overall visibility to customers. Here are the extension points they can use:
Forge
confluence:contentBylineItem
confluence:contentAction
confluence:contextMenu
Connect
system.content.action/secondary
contentBylineItem
system.content.action
system.content.action/primary
atl.general
system.content.action/modify
page.view.selection/action-panel
system.content.action/marker
Why is this deprecation necessary?
As we bring some of our most popular extension points into the Editor to increase their visibility & make apps functional in live-edit pages, we are deprecating extension points that do not work in the Editor or are very unpopular in the Editor to simplify how customers interact with apps, and decision-making for developers. Learn more about the other extension points we are deprecating here.
What is changing? Dates and rollout?
Starting May 8, 2025, the Confluence Cloud system.content.metadata Connect extension point will no longer be available on Confluence pages.
Migration guidance
Check the extension point locations your app is using to determine if your app is using system.content.metadata. Our documentation on Extension Point Locations as well as our Extension Point Finder for Confluence app may be useful.
Update your app configuration to use a location name that’s suitable for your app & not being deprecated. The simplest approach would be to use a location name within the same extension point, as their properties are likely the same. For example, replace the deprecated system.content.button "location" property with system.content.action/secondary, since both are web items. As a reminder, here are the extension points on pages that are not being deprecated:
Forge
confluence:contentBylineItem
confluence:contentAction
confluence:contextMenu
Connect
system.content.action/secondary
contentBylineItem
system.content.action
system.content.action/primary
atl.general
system.content.action/modify
page.view.selection/action-panel
system.content.action/marker
For more info about moving to a new location, check documentation for the location you’re trying to switch to: Content Byline Item, Web Item, Web Panel
Known issues
None so far. We will update this if any come up.
Support
Please feel free to start discussions in the Confluence Cloud category of our developer community, where we’ll be monitoring for your posts. You can also contact our developer support service desk.
Q&A
As we start to field more questions from developers/ partners we will update this section.
Rate this page: