Confluence Cloud extensibility update - Feb 2021: A review and sneak peek into the future

Hi developer community,

Elaine here from Confluence Cloud Product Management, representing the Confluence Cloud Ecosystem team. This is my first extensibility recap post to you all since I started the Ecosystem role in August 2020. Great to e-meet you if we haven’t already.

I want to share some updates on the extensibility work we’ve shipped since the last summary posted on CDAC in July. I’d also like to share what we are currently working on and what our plans are for the next 6 months. This is post #2 of a 3-part series with updates across Jira Cloud Ecosystem, Confluence Cloud Ecosystem, and Migrations Platform. Happy reading!

As you may have learned earlier, our north star for Confluence is to enable a vibrant and rich ecosystem of apps that not only meet but also surpass the breadth and depth of what we have to offer on server today. Over the last 6 months, we saw 38 Confluence cloud apps (and counting!) released to the Atlassian Marketplace, thanks to your dedication and hard work. The focus of our team has continued to be on expanding the Confluence Cloud extensibility with added focus on API reliability, hoping to make it easier for you to provide valuable apps with powerful capabilities, high quality, and great user experience to our shared customers in the cloud.

What’s shipped?

Having heard from you loud and clear, we have been focusing on API reliability issues that had significant impact on your apps and caused you unnecessary effort to troubleshoot, communicate about, and work around them. Here are some of the bugs we have fixed, grouped by feature area:

Copy page or copy page hierarchy

  • CONFCLOUD-70886 - Page links don’t get updated when copying a page tree via copypagehierarchy API
  • CONFCLOUD-70913 - Copying a page tree with restricted page with Copy Page Hierarchy API fails creating page properties
  • CONFCLOUD-69994 - Copying a page with attachments and content properties with Copy Single Page API second time fails with error 500
  • CONFCLOUD-71292 - Copy single page API with custom body does not work anymore
  • CONFCLOUD-70056 - Copying a page with Giphy attachment using Copy Single Page and Copy Page Hierarchy APIs fails due to an attachment size mismatch
  • CONFCLOUD-70325 - Can’t publish edits to pages copied with the API
  • CONFCLOUD-71283 - Body is not changed when copying page with API

Update a page

  • CONFCLOUD-69902 - Updating a page body containing links in storage format via REST API fails

Export from page

  • CONFCLOUD-71297 - Confluence REST endpoint /rest/api/contentbody/convert/export_view doesn’t export emojis


  • CONFCLOUD-70632 - Content search API doesn’t respect OR on ~ operator on title, text fields

We also enhanced API to provide more complete capabilities:

  • Content permissions
    • Added new API to check whether a user/group has proper access to content, space, or site
  • Add/remove space permission
    • Enable space admins to add/remove space permissions
    • Graduated from the previously announced Experimental version
  • Search user group
    • Search for a user group by group name with support for partial match.

There have been some deprecations and changes in case you missed our announcements earlier:

What’s coming next?

ICYMI, you can watch cards on our Atlassian Platform Roadmap for Developers Trello board to see what we’re planning.

IN DEV Attachment update extensibility for file locking

Our goal is to provide Connect-based API/webhooks and UI extension points to power the use case where an app is used for locking an attachment so that only one user can edit it at a time.

We’re dev complete with new and updated Connect conditions to support this use case. Our remaining work is mainly around opening up important file update UI extension points in and outside of the editor. We have planned to deprecate the Companion App in cloud. Some native attachment update features have also been going through a makeover. A technical and experience spike is in progress to identify an approach.

IN DEV Continue focus on API reliability issues

We will continue to fix high impact API bugs that may affect your existing cloud apps or apps you’re building for cloud.

The few API areas mentioned in What’s shipped are still our focus. We also started looking into bugs related with JS API and content rendering.

SPIKING Solve for use cases implemented via nested bodied macros in server

The last summary posted on CDAC in July mentioned our plan to offer, in some fashion, the rich formatting and data manipulation that apps are able to provide today in server via the use of nested macros. We have since then interviewed multiple marketplace partners and gathered a lot of new information on a variety of related use cases, the difference between extensibility in the server editor and the cloud Fabric editor, and how developers have approached and would like to approach their cloud app development in this area.

Here I want to share some of our decisions and plan based on numerous conversations with some of you and in our customers’ best interest.


  • We plan to support migration of nested bodied macros from Server to Cloud legacy editor. We want to help as many combinations of bodied macros as possible, at least the common ones. Our team is actively working on a POC now.
  • We fixed a security vulnerability with existing nested iframes in Cloud legacy editor, an important progress we made to make possible the above mentioned migration support.


  • Our previous decision to not support nested bodied macros in the Fabric editor still holds true , given considerations around security, performance, and usability (WYSIWYG).
  • We want to provide you with a new editor extensibility framework to enable use cases supported by nested bodied macros in server, including new and enhanced extension points in Fabric editor as well as the underlying platform capability to support data communication between macros/apps (a.k.a. chaining).
  • We have grouped all use cases into 6 categories and are currently doing technical and experience design spikes on them. Our solution for each is likely different given technical and experience factors. The timeline when our solution for each will be ready for your integration also varies based on customer impact, availability and ease of workaround, to name a few. We’ll keep you posted once we know more.
    • Data integration , e.g. table data syncing with external DB
    • Scaffolding , e.g. tabs, sub-navigation
    • Advanced table , e.g. table visualization, pivot table, data validation such as column types
    • Workflow , e.g. forms
    • Referentiality , e.g. reuse a block of content or table in multiple pages
    • Content transformation , e.g. translation, custom format

PLANNED Theming extensibility

  • We’ll be making improvement to the Theming API, including refreshing its dev doc to ensure accurate and up-to-date information, fix anything broken, and fill functionality gaps.
  • A new custom site homepage extension point will be provided as the preferred way for apps to provide site level theming capability. The current solution of repurposing a space overview as custom site home will co-exist for a while until the new approach is validated.

Currently available Confluence Forge extension points

The Confluence Cloud Ecosystem team has built multiple extension points and other capability for Forge. Here’s a summary of what we have in place today:

  • Homepage extension point
  • Global full page in Admin Settings extension point
  • Space navigation (side bar) extension point
  • Space full page extension point
  • Space settings extension point
  • Content byline (no dynamic update) extension point
  • Confluence content menu (upon text selection on a page) extension point

What are we looking to solve next with Forge?

  • Dynamic content byline : Forge Content Byline extension point is available. Our plan next is to support dynamic update as triggered by user action or other event.
  • Automation for Confluence extension point : Incorporate 3rd party apps into A4C, in order to support various automation rules / trigger-action combinations between native features and multiple apps.
  • Chaining : Support integration between apps, for example, when an app’s data output serves as input into another app as seen in many use cases supported by nested bodied macros in server today. We want to provide the platform capability to facilitate such data communication in a secure fashion.

We want to hear from you!

If our recent extensibility work helped with the release of the cloud version of your app(s), please share your story and learnings. If your cloud app development depends on or could otherwise benefit from the extensibility work we have in progress or planned, we’d like to learn more about your use cases and any particular requirements or concerns you may have.

We’re also eager to know what other extensibility blockers or challenges you are encountering that are inhibiting you from building more apps in cloud or from reaching critical functionality parity with your server apps. It would be super helpful if you could share these additional details:

  • What specific app is the extensibility blocker impacting?
  • What alternative solutions/workarounds have you explored? What was the outcome?
  • For parity issues such as those related with nested bodied macros,
    • what functionality and/or user experience is compromised and how?
    • what percentage (rough estimate) of the app’s customers, use cases, or usage are affected?

Please share your story, feedback, and questions in the Comments of this post.

As always, you can raise a bug or feature request with the following teams:

For Confluence extension points, API, and webhooks:

  • Report bugs here
  • Give suggestions here

For Forge dev platform features, submit requests here


Awesome job Confluence!

Great post @ElaineH, really appreciate this!

Is that not already live? Played around with it a little and it seems to work great so far. Love this new endpoint! But since you’re saying it’s still in development, should we wait a bit before using it in production?

This sounds amazing! Really excited to hear more about that! :smiley:



Hi Sven! Glad what we’ve been working on is helpful to you. Regarding “API for searching user group”, our engineering team is ahead of the game! It’s indeed live already. I updated the post to reflect the same.


I’d like to hear more about that, as I’m currently making use of the legacy approach, but also if there is an opportunity to do more through theme-related customisations.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.