Getting 503 error while calling confluence API

Note that API URL like works when opened in the browser after logging on to Confluence. Still HTTP 503 using previously working OAuth flow.

@ibuchanan We are facing the same issue for groups, users, content searches using the confluence REST API.

All these endpoints worked seamlessly earlier, with the OAuth token and the org endpoint, but has stopped working now, giving the same error mentioned above.


@PatrickHofman @GuidoLeenders @SheetalShetty

I can appreciate how frustrating it is when code that works, suddenly doesn’t. I certainly believe you that it used to work the way you wanted it. However, OAuth tokens weren’t meant to work with the same base URL as the UI and other REST API auth options. As I pointed out, the 3LO documentation shows that you must use the common API proxy, not the base URL for the site. (Yes, I understand how confusing the REST API docs are on this matter, given they were written with older routing and auth mechanisms in mind.)

Although I have no doubt that something broke your code, I don’t know which change did that. And even if I knew the change, I can’t classify it as a defect or incident because it was unspecified behavior (at least according to engineering’s interpretation). Hence, all I can tell you is to use correct URL pattern:{cloudid}/{api}

1 Like

@ibuchanan Although the OAuth documentation mentions that we must use the common API proxy, this feature did not work when we were working the REST APIs earlier. I had also raised a support request(ticket) then, following which, we had to resort to the Org base URL instead(as it was the only way REST APIs were working) and pushed the changes to Production, hoping we would have the continued support for it.

@ibuchanan We already updated our code to work with the assumed correct API url. However, as requested, please update the documentation accordingly. Not for us, but future developers debugging for hours.

1 Like

Hi @SheetalShetty,

I work with Ian and I will be helping out here from now on.

I have a question about your message, I saw the comment on the support ticket and the earlier community post and I wanted to confirm that the issue is the the one reporting in your comment here:

Can you please let me know?

I’ll try to test it myself as well, but it might take me a few days so if you can confirm the exact problem, that’s going to help me a lot.



Hello @PatrickHofman,

Let me bring this up with the relevant teams and make sure that the documentation update is on their radar.

Thank you for letting us know that the code has been updated now. If anything unusual comes up, please let me know by commenting here (also feel free to mention me directly) and I’ll look into that right away.



@ccurti Yes, that’s right. And this was the case for all Confluence Cloud APIs.

Hi all,

Let me try to add some clarity and context to this thread.

What changed?
The affected APIs were not intended to be working when using the site URL, this incorrect behaviour has been addressed and that’s why they are now returning a 401 status code.
The way forward is to always use the format when accessing the affected API endpoints.

This is documented for “OAuth 2.0 (3LO) apps” on the page.

We understand that this should have been communicated beforehand and we will do better in the future. This topic has been brought up with all the parties involved and we will improve our processes to make sure that the right communication with the right notice is provided.

Why 503?
While deploying the change, for a limited amount of time, when using the site URL format, the APIs have been returning a 503. This wasn’t intended and all affected APIs have been updated to return 401 as status code.

What about the incorrect documentation?
A few documentation pages are still mentioning the site URL format in the examples, this will be addressed as part of the bug report.
If any other pages, that are not mentioned on the bug report, are also affected, please add a comment to the CONFCLOUD-72411 directly.

I hope I covered all the concerns expressed in this thread with this reply. If not, please let me know and I’ll get back to you.

Thank you,


Hi @ccurti
Just to confirm, has the Base URL also changed from to ?


My bad @SheetalShetty1 , no changes there.

Let me fix my comment above.

Update: fixed now.

1 Like

Hi @SheetalShetty1,

Let me answer your comment here directly, while I’ve addressed the broader topic here: Getting 503 error while calling confluence API - #14 by ccurti.

When using the{cloud-id}/{api} API, if the returned http status code is 401 the problem is most likely with the app not having the correct scopes set and therefore. To prevent that, please make sure that the correct scopes are specified when requesting the authorization code.

If you think something else is happening, let’s keep the conversation going in the original thread.

I’ll cross-post my reply there as well.




I recently created the topic about related problem here: Downloading attachments content using OAuth2 from the Confluence - #5 by PrzemysawKanach but this place seems to be fine to address it.

So the breaking changes described here made that downloading attachments’ content is no longer possible using download_link because it doesn’t work with the OAuth token.

Are there any plans to fix the issue or you have any advice how to download attachments content using OAuth token?

The code which doesn’t work any more:

curl --location --request GET '<MY_INSTANCE>/rest/api/download/attachments/<ATTACHMENT_ID>/sample.pdf?version=1&modificationDate=1615204617358&cacheVersion=1&api=v2' \
--header 'Authorization: Bearer TOKEN'

Thank you in advance,


This is also a gap for us - we’ve been relying on the ability to download attachment binary content via the download link for years with an OAuth 2 token.

Would it be possible to re-enable this functionality, with an announced EOL? This change has effectively broken what was previously documented expected behavior. It may not be documented now, but it was previously, and shows that there are still areas where this is documented as supported behavior. This kind of backwards-incompatible change, with no warning, really leaves your customers and integration partners up a creek.

Hi @PrzemysawKanach and @RandySwift,

Thank you for your patience. There is now an incident on the developer statuspage about this.

Here is the direct link: Atlassian Developer Status - Attachments download using OAuth in Confluence

Please subscribe to it for updates, including potential workarounds.

Thank you!

1 Like

Hi @RandySwift ,

We will not be able to re-enable this functionality. I understand that this is not ideal but it is not possible at the moment.

Is your concern about the update from the site URL format to the api URL format?

The reason why I’m asking is because, as I posted below, there is now an incident about the Attachment downloads: Atlassian Developer Status - Attachments download using OAuth in Confluence.

Thank you,

Currently Jira REST APIs are working fine with the base URL as site URL.
Is this also going to be deprecated? If yes, then what is the timeline to move to new base URL (


If it works, it’s a completely “undocumented feature”. The 3LO documentation makes it clear to use the URLs. That means if you depend on the undocumented behavior for Jira, it is not subject to policy so it could be changed without deprecation notice and on any timeline. As evidenced by the inconvenience of other developers on this thread for Confluence, undocumented features can and do change without notice.

To be fair, I know there is some disagreement about how clearly this was documented. Where the 3LO docs are clear, the REST API docs are less so. But this thread now makes the Atlassian intent clear for both products so please consider this thread an informal “notice of deprecation” and move as soon as you can.

@ibuchanan Thanks for the clarification.