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.
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.
Rollout: progressive rollout by tenant IN PROGRESS
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:
When granting update access, you also include the read restriction for that principal.
Your logic for removing restrictions accounts for the fact that read access is now a prerequisite for update access.
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.
Dynamic modules, customer-managed egress, and customer-managed remotes are now generally available on the Forge platform.
Dynamic modules let a Forge app register and manage modules at runtime through the Dynamic Modules API, rather than declaring them statically in the manifest. These modules are available across Jira, Confluence, and Jira Service Management.
Customer-managed egress lets Atlassian administrators configure the external domains a Forge app may send data to.
Customer-managed remotes let Atlassian administrators configure the remote backends a Forge app may communicate with.
For more information, see Dynamic modules and Customer-managed egress and remotes.
These capabilities are not currently supported for Atlassian Government Cloud.
These capabilities follow their earlier Preview releases: Forge Dynamic Modules Preview and Customer-managed egress and remotes Preview.
We’ve fixed an issue where remotes referenced in permissions.external.fetch.client only allowed the default base URL, causing browser requests to regional endpoints to be blocked by the content security policy (FRGE-2205)
You can now read your app’s remote installation region using remoteInstallationRegion in getAppContext(). Adding a client-fetch URL that already exists in fetch.backend now results in a minor version change. See app versioning.
Confluence Cloud will enforce approval-required publishing for direct page updates made through the Confluence REST APIs. In spaces where admins require approval before publishing, direct updates to published pages will return HTTP 409 Conflict. Integrations must save changes as a draft, complete the approval, and publish the approved draft.
This affects PUT /wiki/rest/api/content/{id}, PUT /wiki/api/v2/pages/{id}, and PUT /wiki/api/v2/pages/{id}/title. It applies only to regular pages in spaces configured to require approval; other spaces and content types remain unchanged. We will update this entry with the rollout date before enabling the change.
🛠️ Scheduled maintenance window from September 25 @ 5PM PST to Monday, September 28 @ 10AM, AEST
Our support portal is moving to a new home. New ticket submissions and ticket access including comments via email will be unavailable during this window. Starting September 28, submit all requests at Atlassian Support and update your bookmarks. Learn what's changing.
Rollout: progressive rollout by tenant. COMPLETE
Upgrading a Connect app installation to a Forge-only version previously called the Connect uninstalled lifecycle hook before the Forge installation event fired. This was indistinguishable from a customer uninstalling the app.
The uninstalled hook is now suppressed for both migration paths:
an already-harmonised (Connect on Forge) app installation upgrading to a Forge-only version
a Connect app installation upgrading directly to a Forge-only version under the same app key
The Forge platform will undergo maintenance in FedRAMP production on 13 September 2026 between 23:00 UTC and 00:00 UTC on 14 September.
There may be up to 30 seconds of write-operation downtime within this maintenance window. During that time, creating, updating, deleting, deploying, installing, uninstalling, or upgrading apps, and granting or revoking app access and consent, may be intermittently unavailable.
Existing app invocations will continue to work. Users should retry a failed write operation after maintenance completes.
What's changing
Apps adopting Forge from Connect can now use the migratedFrom property in a Forge macro module to map one or more existing Connect macro keys to a single target Forge macro. This allows you to consolidate multiple legacy macros into a new Forge implementation.
Key details of this feature:
Resolution: Existing Confluence content that uses any of the listed Connect macro keys will automatically resolve to the target Forge macro.
Scope: The listed keys must belong to the Connect app declared in the app.connect.key field of your manifest.
Responsibility: The target Forge macro is responsible for handling the configuration and parameters stored by the previous Connect macros. Note that migratedFrom does not transform parameter schemas.
Exclusivity: A legacy macro key can be claimed by only one Forge macro on a given tenant.
Current limitation: Forge-to-Forge macro consolidation is not currently supported; this property only supports mapping Connect macro keys to Forge macros.
What you need to do
To consolidate your Connect macros, update your manifest.yml file to include the migratedFrom property under the target macro module:
1
2
3
4
5
6
modules:
confluence:macro:
- key: consolidated-macro
migratedFrom:
- old-connect-macro-a
- old-connect-macro-bFor more information on migrating macros and handling legacy data, refer to the Adopting Forge from Connect: Migrate macros documentation.
By mapping legacy Connect macro keys to a Forge macro, migratedFrom helps existing Confluence content continue to resolve correctly during the app-user migration to Forge. For background, see CONFCLOUD-84508.
Bitbucket pull request (PR) update events for Forge apps now feature an additional changes field in their payloads. This field is present when a PR is updated due to a new commit being pushed to the source branch.
This update allows Forge apps to distinguish between code-level updates (new commits) and metadata updates (such as changes to the title or description). This is a backward-compatible change; no existing fields have been removed or renamed.
What you need to do
For most apps, no action is required. If your app is already listening to Bitbucket PR update events, the additional field will automatically be available in the event payload.
However, if you validate event payloads with a strict schema, ensure your validator is updated to allow the new changes property. You can review the updated payload structures in the Bitbucket pull request updated event reference documentation.
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.
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-140-updating-categories-in-the-editors-element-browser/101855
We are deprecating the workflowId field in the webhook payloads sent to Connect workflow Post Functions. This field now returns a placeholder value, and will be removed after 31 July 2027.
The workflowId is an invalid value and may lead to bugs in your applications if used. It references an internal identifier that does not correspond to a workflow and cannot be mapped to any workflow in our public APIs.
If you are using workflowId, you should instead use workflowName or workflowEntityId, both of which contain values that can be used to correctly identify workflows.
What's changing
The workflowId field in webhook payloads triggered from Connect workflow Post Functions now returns a placeholder value. The field will remain in the payload until it is removed after 31 July 2027, but its value should not be relied upon.
Why
The workflowId value references an internal identifier that does not correspond to a workflow. It cannot be used to query or identify workflows through our public APIs, and using it can cause unexpected behaviour or bugs in your app.
What you need to do
Before 31 July 2027:
• Identify any integrations that read workflowId from these webhook payloads.
• Replace usages of workflowId with workflowName or workflowEntityId.
See example connect trigger below:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
"configuration": {
"value": "Configuration from the post function edit page"
},
"issue": {
"fields": {
...
},
"id": "10000",
"key": "TEST-1",
"self": "http://issues.example.com/jira/issue/10000"
},
"transition": {
"from_status": "Open",
"to_status": "Resolved",
"transitionId": 5,
"transitionName": "Resolve Issue",
"workflowId": 99999, <-- deprecated, no longer used.
"workflowName": "example workflow"
"workflowEntityId": "<some UUID>" <-- newly added, should be used.
}
}
Rate this page: