Getting 503 error while calling confluence API

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.

Hey @ibuchanan , @ccurti
I understand that going ahead “…” is the right way to use an API using OAuth 3LO.

My doubt is regarding the basic authentication, at present the “https://{instanceUrl}/rest/api/3…”
format is working fine and is documented here : Basic auth for REST APIs

But in REST API documentation, everywhere it is suggested to use the “…” way to call the APIs.

Can you confirm the right behaviour for basic Authentication ?


Thanks for clarifying what you meant by “Currently Jira REST APIs are working fine with the base URL as site URL.” In a thread on OAuth 2, I was sure you meant using OAuth.

Basic auth with API tokens remains working for the instance URL. I am not aware of any plans for that to change.

Hi @ibuchanan @ccurti

All Confluence Cloud rest APIs are failing for me with this message :
{“timestamp”:“2021-09-14T15:12:11.782Z”,“status”:404,“error”:“Not Found”,“message”:“No message available”,“path”:"/ex/confluence/xxx/wiki/rest/api/group"}

Are you guys aware if any changes has been made to the APIs ?

I am using OAuth token with as the Base URL and I am also able to hit the accessible-resources API successfully. But any other groups, users, content APIs do not work and break with the same error.


New error, new thread please. When you do post, we’ll probably need more context. For example, maybe what scopes you have, or anything else about the OAuth app details. Have you started using rotating refresh tokens yet?

But quick answer, I don’t see anything in the changelogs to indicate this problem. I also ran through a quick OAuth flow and API call with an expected result (200 and a real payload).

@ibuchanan Created a new topic here : REST API errors with 404:No message available
Please have a look at the details.