Dynamic Modules for Confluence Cloud

We’re happy to announce that we’ve just released Dynamic Modules for Confluence Cloud!

This means that in addition to defining Connect modules in your app descriptor, you can also register and remove modules on the fly with a set of new REST APIs.

The modules that are able to be dynamically registered include:

Currently, you can dynamically register a maximum of 10 modules in your app. We’re monitoring and will evaluate raising this limit in the near future. These REST endpoints are currently labeled “Experimental” during this monitoring and evaluation phase.

Here are some examples of new workflows that can be implemented with dynamic modules:

  • A list of web items that change dynamically based on an external source (eg, active OpsGenie incidents)
  • Giving users the ability to create their own macros
  • Improving the performance of your app by only listening to the webhooks that you actually need, and being able to change that on the fly

For more information, see the documentation on Dynamic Modules.


Awesome! Sadly it will take me a few months until I will have the necessary time but I have such a great use case for this! :heart_eyes:

Very much looking forward to putting this to use!

@rwhitbeck This is good news, but unfortunately dynamic content macros don’t work yet for our purposes, so I’m hoping this gets expanded to static content macros.

I tried adding dynamic macros using this API last week and ran into these two issues:

The macro browser in the editor did not contain the new macros after they have been created.
This is related to https://jira.atlassian.com/browse/CONFCLOUD-58280 I think because clearing the browser cache for my site fixed it.

After the macros showed up as expected suddenly I only saw the generated i18n keys (by macro name convention) instead of the name I’ve submitted when creating the macro. Obviously my app does not provide any i18n for generated macros - and I think it should not be assumed that the app does that because the macro name might not be defined by the app vendor but the end user at runtime. I created the macro with this JSON:

    "dynamicContentMacros": [
            "url": "/macro-html?macro-id=id123",
            "description": {
                "value": "Test macro"
            "outputType": "block",
            "bodyType": "none",
            "parameters": [],
            "name": {
                "value": "Test"
            "key": "dynamic-test-macro-1"

Is this expected?

Is Atlassian going to deliver this functionality as part of out of the box Cloud functionality or are you leaving this open to marketplace vendors to provide solution?

(I saw what looked like a prototype of this demonstrated at Atlas Camp)


Is Atlassian going to deliver this functionality as part of out of the box Cloud functionality or are you leaving this open to marketplace vendors to provide solution?

Marketplace Vendors can definitely provide a unique solution to customers using Dynamic Modules and is a use case we support.

I think the prototype you’re referring to was Forge, which we just announced (again) late last week.

@rwhitbeck There was a demo of an example app in this presentation, talking about a “Custom Macro Creator” as part of Supercharge Your Pages - New Ways to Extend the Confluence Editor:

I can see all sort of potential for this, but I want to clarify if Atlassian is intending on providing customers with a basic custom macro creator like the demo out of the box?
1 Like

@rwhitbeck are you able to confirm the persistence of dynamic modules across the lifecycle? It looks like when you uninstall an app and reinstall, the dynamic modules are left unchanged? And should it be possible to add a dynamic module as the app installed?

@rwhitbeck I have an app that was able to set a dynamic module when the enabled lifecycle webhook was received for a new install. However, I’m now getting a “403 Forbidden” response when I try to interact with that endpoint in response to the app being enabled. This was working before and I can set it successfully a few seconds later after the install is completed. Has something changed?

UPDATE: So after some experimentation, I added a 10,000 millisecond delay to my enabled function before it attempts to interact with the dynamic module endpoint and I no longer get the 403 error. Is this expected behaviour?

1 Like