Using AP.request to fetch content from the Confluence host has recently stopped working?

I have a number of dynamic macro add-ons for Confluence, that use AP.request to fetch the macro body content via the Confluence REST API.

Recently this seems to have stopped working, and I was wondering if anyone knows if something changed in the REST API that might explain this?

Example code that was previously working, and now isn’t is:

  .then(data => console.log(data))
  .catch(e => console.log(e));

I don’t see anything logged in the browser console, and there are no requests in the Network tab to indicate that the REST API call is even being made?

I can confirm that the REST endpoint URL is correct, as I’m able to append it to my Confluence instance URL + context and paste it into the browser address bar, which returns the JSON as expected, e.g.

I can also use a plain fetch() request with CORS from the host Confluence page’s context, and it too returns a successful 200 OK response with the JSON as expected:

fetch('/wiki/rest/api/content/30509981/history/140/macro/id/102cd177-0549-4668-988a-4b2ba2590ae7', {credentials: 'same-origin'})
  .then(data => console.log(data));

The problem only seems to be occurring when using AP.request to call the REST API from the add-on’s iframe context.

1 Like

Also, not sure if this is relevant; but I’ve noticed the following errors in the browser console that I can’t say I’v e noticed previously:

Failed to execute 'postMessage' on 'DOMWindow':
The target origin provided ('')
does not match the recipient window's origin ('https://[INSTANCE]').

I know that Atlassian Connect uses postMessage to communicate between the add-on IFRAME and the parent window; so perhaps this is what has caused AP.request to stop functioning?


We observe the similar issue. ‘xdm_e’ param now serves different url for macros view. Before it always was instance host and now it refers https://* (it depends on your location).

It seems that they are optimizing the JS client library location.


Same here. Both of my Cloud plugins stopped working on Friday.

1 Like

This is hitting now, we’ve 12k cloud instances and had to pull the whole engineering team in on a Sunday to look for workarounds.

Do Atlassian provide out of hours support for API showstoppers? If not, maybe avoid releases directly before the weekend in future?


I logged a support request with Atlassian (in the DEVHELP service desk) almost 24hrs ago, and I’ve been updating the ticket with additional info as it comes to hand, such as the fact that other vendors like yourself are also impacted.

I would recommend that all vendors affected also log tickets (not sure if there is a better place than DEVHELP that may be treated with higher priority?), to help convey the urgency of the issue.

It seems quite out of character for Atlassian to introduce such a major issue and then seemingly have no one on call to monitor for issues.

1 Like

The xdm_e parameter is indeed wrong and we can’t get the parent URL. Just…wow… We’ll file a ticket.

1 Like

This is impacting both of our Confluence apps that use Dynamic Macros. The same errors.

1 Like

Hi Everyone,

Thanks for letting us know about this and for raising it in the Developer Support portal. An incident report is raised already and fixes are on its way. You may watch the progress here:

Anne Calantog


Thanks @acalantog, appreciate the update.

Once resolved, I hope there will be a post-mortem published of what the underlying cause was.

It goes without saying that this has caused significant reputation damage to all affected vendors.

The end-customer experience has been “the vendor’s add-on is broken” (not “Confluence is broken”), and it will be impossible to know how many potential sales might have been lost as a result.

For it to have been three days with seemingly zero acknowledgement from Atlassian is very concerning.
I refuse to believe that Atlassian has no monitoring/support of its Cloud infrastructure on weekends, and I would like to think that Atlassian were aware of the issue and working on a fix well before the incident report was logged today.

(I appreciate that you are - most likely - not personally responsible for the problem, so these comments are of course not directed at you).

Kind regards,


Glad to see Atlassian have finally updated their status page with reference to the issue.

At least this gives us somewhere to direct our customers for tracking the issue; and lends some credibility to our support team’s claims that the problem is entirely out of our control.

Hi @scottohara,

Issue is resolved. Apps should be working now. Statuspage also updated. Let me know if there’s still some issues.

Anne Calantog

1 Like

Thanks @acalantog, can confirm everything is working now.

@acalantog It is unstable at the moment. In our main development instance, it works in some spaces and still broken in other spaces.

AP.request: fine now

However I’m unable to confirm that the xdm_e issue is solved. In my case it helped to determine the baseURL via hostUser.getHost().getBaseUrl() on the server for my static macros.

We are experiencing the issue again on space home pages.
Worse yet is when I go to edit any page I get a blank page with a spinner in the middle and it never returns.
I’ve tried several different test instances.


Hi @jeff,

Thanks for notifying us in DEVHELP, we’re able to coordinate the issue in Confluence Team. Will keep you guys posted.

Anne Calantog

Hi Everyone,

Update. Fix has been rolled already. Let me know if something’s not right.

Anne Calantog