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.
To improve performance and address constantly evolving threats on the web, Atlassian is enabling AWS Cloudfront Content Delivery Network (CDN) and Web Application Firewall (WAF) for all Confluence and Jira Cloud Customers.
This rollout will occur over the next few months, country by country, progressively, with each country taking around 1-2 weeks to complete the migration.
This improvement may unfortunately impact some Jira and Confluence Cloud API integrations (like those written in Python, Node/JS, Java, libcurl, Axios, atlassian-connect-express etc) that attempt to make requests with URLs (including path and query string) longer than 8192 characters/bytes.
Where previously Jira and Confluence Cloud APIs handled paths longer than 8192 characters/bytes, AWS Cloudfront will actively reject such requests:
The maximum length of this URL is 8192 bytes.
If a request or a URL exceeds these maximums, CloudFront returns HTTP status code 413, Request Entity Too Large, to the viewer, and then terminates the TCP connection to the viewer.
Unfortunately, it is not possible to configure Cloudfront to allow longer URLs.
Atlassian products such as Loom, Trello, Opsgenie, Statuspage etc already reject 8192 characters/bytes urls.
For resolution instructions see more details below.
To resolve the issue, break up API calls into multiple requests, or restructure your API call such as using labels or field filters instead of enumerating individual work items.
I saw the error in my Chrome/Firefox/Edge/Safari etc browser
If you observed the aforementioned error in your browser please contact Atlassian Support, and ideally include the full text of the error, including Trace ID, and a HAR file covering the error: https://confluence.atlassian.com/kb/generating-har-files-and-analyzing-web-requests-720420612.html
We have removed the following request body fields from the Update custom content REST API V2 endpoint:
spaceId
pageId
blogPostId
customContentId
These fields had no effect, so there is no impact on any clients who currently use them.
The V2 Create blog post API and V2 Update blog post API now support createdAt date field in the request body. This can be used to create blog posts at a future or past date. In the V1 Create content API, this could be used to bypass the title validation if another blog post with the same title was created on the same day. This has now been brought to V2.
Similarly, in the V2 Update blog post API, updating a blog post from draft status to current status essentially publishes the blog post. During this operation, the createdAt field can also be used to bypass the title validation.
Example request body for V2 Create blog post API and V2 Update blog post API:
1
2
3
4
5
6
7
8
9
10
{
"spaceId": "<spaceId>",
"status": "current",
"title": "Example title",
"body": {
"representation": "storage",
"value": "Content body"
},
"createdAt": "2025-02-28T21:41:06.157Z" <- New field
}We’ve added new query parameters include-direct-children, include-operations and include-properties for the following V2 APIs
By default, these parameters will be set to false.
Live Docs are now available in the Confluence Cloud V2 REST API for tenants in the Live Docs early access program (EAP) and tenants in the Developer Canary Program. Further API details are listed in More details.
To learn more about Live Docs, please read our open RFC & provide feedback: https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495
To create a Live Doc, use the field "subtype" : "live" in the request body for Page Create endpoint.
The existing behavior for creating a Page will stay as it is i.e for creating a Page no subtype field is necessary.
The Page API response for Live Docs will contain an exclusive field called subtype with value live.
This subtype field will not be present for pages.
Bulk Get pages by default will return both Pages and Live Docs. The endpoint will support an additional query parameter subtype which can be specified as page for Pages and live for Live Docs.
1
2
3
/pages?subtype=live -> Get Live Docs Only
/pages?subtype=page -> Get Pages only
/pages -> Get both(Live Docs and Pages)We will remove support for Automation incoming webhooks that reference the automation.atlassian.com domain. Webhooks created before 28 January 2025 are affected. Applications that trigger rules via those incoming webhooks will need to change the URL they use, and add an additional HTTP header. Expand the details for more information.
We're updating the incoming webhooks trigger in Atlassian automation. This update is part of our continuous focus to uplift the security and reliability of automation.
We are deprecating the domain automation.atlassian.com for incoming webhooks, and replacing it with a more secure endpoint in a different domain. The URLs to trigger webhooks have a different structure, and an additional HTTP header is required. The webhooks that use the old domain automation.atlassian.com will stop working on 30 May 2025.
All new rules created since 28 January 2025 are already using the new endpoint and header, and no action is required.
Rules with incoming webhooks created before 28 January 2025 will work normally until 30 May 2025 without any change. However, for these rules to continue working after that date, manual changes are required to use the new endpoint before 30 May 2025.
To migrate existing rules to the new endpoint, follow these steps:
Open the Automation rule list in Jira or Confluence.
Click on the ‘Trigger' filter and select the ‘Incoming webhook’ filter. All rules containing an incoming webhook trigger will be shown.
Open one of these rules in the rulebuilder and select the trigger component.
Copy the new URL and secret.
Enter the new URL and secret into your connected application, and add a new HTTP header with the name X-Automation-Webhook-Token. The method to do this can vary between applications, so you may need to check what the instructions are for your application. If your application does not support custom HTTP headers, you can instead insert a slash at the end of the URL and add the secret after this. For example, https://URL/SECRET. This will allow you to update your rules without the need for a HTTP header. However, we recommend using the header if possible, as it provides more security for your secret.
You can verify if the new URL successfully triggered your rule by visiting the audit log after it runs.
Repeat the above steps for all rules containing an incoming webhook trigger.
The navigate and open methods from the @forge/bridge router API now allow you to programmatically navigate to select locations using a NavigationLocation object instead of a URL.
This capability is in Preview and is supported across Jira and Confluence modules for both UI Kit and Custom UI.
For more information on the NavigationLocation object, refer to the router documentation.
Update to the latest version of @forge/bridge with npm install --save @forge/bridge@latest
To improve performance and address constantly evolving threats on the web, Atlassian is enabling AWS Cloudfront Content Delivery Network (CDN) and Web Application Firewall (WAF) for all Confluence and Jira Cloud customers.
This rollout will occur over the coming months, country by country, with each country taking around 1-2 weeks to complete the migration.
This improvement may unfortunately impact a small number of Jira and Confluence Cloud API integrations (like those written in Python, Node/JS, Java, libcurl, Axios, atlassian-connect-express, etc) that are accidentally including a body/data/payload in GET requests.
Such requests will no longer have their body payload silently discarded and continue to be processed. Instead, they will be rejected with a HTTP 403 response code.
Atlassian products such as Loom, Trello, Opsgenie, Statuspage etc already reject GET requests with Body payloads.
For resolution instructions see more details below.
Previously Jira and Confluence Cloud APIs silently discarded any body included with a HTTP GET request and continued to process the request as normal. Unfortunately, AWS Cloudfront will actively reject such requests:
If a viewer
GETrequest includes a body, CloudFront returns an HTTP status code 403 (Forbidden) to the viewer.
HTTP clients (other than browsers) that attempt to include a body with a GET request will observe a HTTP 403 response code, with text like the following:
1
2
3
4
5
6
7
8
9
403 ERROR
The request could not be satisfied.
Request blocked. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner. If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront)
Request ID: L23_HKTRmXpYbGS8c9dcwq-Zy5fx3_a7htuNzMlvJE6rW814efVx2h==Unfortunately, it is not possible to configure Cloudfront to preserve the existing silent discard behavior which previously allowed these malformed requests to be successful.
To resolve the issue ensure that your HTTP client code for your API integration does not include any body with its GET requests. These are never necessary and were previously discarded.
We have found that some developers are not even aware their program or script is including a body with a GET, and the most common body payloads are as follows:
1
2
3
4
5
{}
""
''
If you observed the aforementioned error in your browser then the underlying cause is different, as browsers do not send GET requests with a body.
Please contact Atlassian Support, and ideally include the full text of the error, including Trace ID, and a HAR file covering the error: https://confluence.atlassian.com/kb/generating-har-files-and-analyzing-web-requests-720420612.html
Reminder: Starting Apr 30, 2025, a subset of Connect extension points will no longer be available on Confluence pages. For details, see the original deprecation notice linked below.
deprecation notice Deprecating a subset of Confluence page extension points.
include-collaborators optional-field is now supported in the following V2 APIs:
This will list the users that have made changes to these content types. See “More details” for an example.
Example:
Adding ?include-collaborators=truein the above APIs will result in
1
2
3
4
5
6
7
8
9
10
11
{
...
"collaborators": [
{
"accountId": "<collaboratorUserId>"
},
{
"accountId": "<collaboratorUserId>"
}
]
}Previously retrieving collaborators would require calling the Version V2 API for every version of the content. Now this can all be done from a single call.
The V1 Get URI to download attachment API now supports retrieving attachments with specific statuses via the query param status. Previously only attachments with the current status can be retrieved. See “More details” for an example.
Single status example:
Adding ?status=draft on V1 Get URI to download attachment API will retrieve an attachment only if its status is draft.
Multi-status example:
Adding ?status=current&status=draft on V1 Get URI to download attachment API will retrieve an attachment it’s status is current or draft.
Until now, the first version of an app to adopt Forge features or migrate fully to Forge required admin approval in order to be upgraded on an existing installation site.
Connect apps moving to Forge can opt-in to have their existing Connect installations updated to their latest Forge version, as long as they do not have an elevation in permissions. The rollout will be staggered over 96 hours by default, but can be further staggered via the staged migration process.
Instructions on how to opt your app in to this feature and check its eligibility can be found at Minor version updates (Connect to Forge) (Preview).
The Rovo agent and action modules are now generally available.
Get started with the Build a Rovo Agent hello world app tutorial.
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495
Rate this page: