Dynamic macro properties after edit

I’m creating the dynamic macro using ACE and I’m having troubles with reading macro properties when editing page after macro is updated.

Here is my situation…
I have ‘dynamicContentMacros’

"modules": {
        "dynamicContentMacros": [{

in the macro there is a parameter

"parameters": [
                    "identifier": "name",

Here is what I do:

  1. Go to Edit Page
  2. insert macro to the page
  3. click ‘Edit’ icon on the macro
  4. change the name on the edit dialog
  5. save it

After edit dialog is closed the dynamic macro is reloaded.
Inside the macro I do AP.confluence.getMacroData() call to get macro parameters.

The problem this that it returns outdated (previous) value of the ‘name’ field. As a result on the edit page after editing macro properties the old version of the macro is displayed. That is very confusing.
I’ve tried various ways to get the data updated and nothing helps. Data is also not updated if you send the request later (like 10 secs after it was edited) etc.

The only way to resolve the issue is either Publish the page, then on the ‘view page’ mode the AP.confluence.getMacroData() will give the updated value. Also it is possible to refresh the edit page, then the value will be updated as well.

I’ve tried to resolve the problem by reading the macro parameters using REST API call

GET /wiki/rest/api/content/{id}/history/{version}/macro/id/{macroId}

It works fine when the macro is on ‘view’ page and first loaded on the ‘edit’ mode. After editing the parameters of the macro the API call starts returning 404 error until page is published.

com.atlassian.confluence.api.service.exceptions.NotFoundException: No macro found on content id : ContentId{id=1336180753} with version: 38 and macroId: be87d90f-fe24-4992-b372-936022f4e2ff

The only reliable way I found to get the updated parameters is from the URL request parameters.

"url": "/v1/macro?pageId={page.id}&pageVersion={page.version}&macroId={macro.id}&name={name}",

The problem is that potentially the data can be very long (not for the name but other parameters) and it can potentially harm the browser, server etc.

Am I doing something wrong here? Is there a way to make things work properly? Is this a bug and should I create a ticket? Where?

Andrey Stepanov

Hi @stepashka
From your description, this might be related to: https://jira.atlassian.com/browse/CONFCLOUD-71216

Thanks @marc. It is indeed looks like the same issue. Issues’ ‘low’ priority doesn’t sound very promising. Will have to use a hacky way to overcome it for now.

Doing some more digging I found more related topics:

This is a huge issue for us, and it has been reported multiple times. Many tickets were closed, and then new reopened… tired of chasing this, really.
Something that is more active https://jira.atlassian.com/browse/CONFCLOUD-69962
We have basically solved this like this (someone on the community posted an idea):

  • we generate a hash of parameters and send it to our backend + the macro parameters (json)…
  • then we try to read the macro params from OUR backend instead of Atlassian (by macro hash we have generated)
  • macroHash is the real hidden parameter in the macro and you can set up your macro to be called with a macro parameter in the url
"url": "/form/render/css-rule/{content.id}/{content.version}/{output.type}/{macro.id}/{macroHash}"

So, Atlassian connect framework will get the “macroHash” parameter value and call our rendering url with this parameter

If you have very low number of parameters and they have a limited length (bare in mind the url length limitation) then you can set up your macro “url” parameter to have all the params in the URL…

There is some clean up logic of course, but is omitted here for simplicity…

Hope it helps


Thanks for the advice. I’ll stick for the URL parameters for now, hoping that issue will be resolved soon.
Storing customer information on site would require another level of development and more importantly security.
I’m also looking to migrate to Forge some time soon. Hopefully it can resolve this issue as well.


I’ve noticed some strange behaviour of macro after edit.
macroId on the page (getting page content using GET /wiki/rest/api/content/{id}) and macroId obtained from request params, from context or from getMacroData are different. There is no way to get the new macro ID. After page is published the id becomes the same.

I used this way to detect if data is stale and show warning. The best I can do for now :frowning: .

1 Like

Exactly! The macro id changes!


I repeat - you cannot do GET /wiki/rest/api/content/{id}
there is no contents in the backend (yet… when you edit the page in the new editor. Hit this wall 2 years ago and still it is not resolved (and not even fully acknowledged :frowning: ))