HI Team,
We are getting a 503 error while calling confluence API. Please see the attached screenshot for reference.
The issue is similar to the issue described in this post: https://community.atlassian.com/t5/Confluence-Cloud-questions/What-does-quot-503-Service-Unavailable-quot-mean/qaq-p/1734672
Can you please guide us what may be the root cause of this?
@Zluri, welcome to the Atlassian developer community.
We really need more context to understand the problem. Could you provide context of the request you are trying to make? And with which authentication? Other information like which app framework (if any) or programming language (or tool) will likely help as we understand more.
We have an OAuth 2.0 integration APP.
Once we are able to fetch access token ,we make call to wiki/rest/api/templates/page API.But its giving 503 Service Temporarily Unavailable error.
Check this screenshot for details.
This was working few days back.
We are able to generate access token and call https://api.atlassian.com/oauth/token/accessible-resources to get the url.
But any confluence specific api always gives 503 error.
Looking at your request URL, it doesnât fit the pattern described in the 3LO documentation: https://api.atlassian.com/ex/confluence/{cloudid}/{api}
I canât explain why the response has a 503 status with a result page that claims it is a 401. Thereâs a bug somewhere in there. But I can confirm that when you use the site-specific URL pattern (as works with API tokens but doesnât work with OAuth), then you get that 401-hiding-inside-a-503 error. If it was working a few days back, it wasnât with OAuth.
@ibuchanan That might be the problem we are experiencing as well. This worked for sure for a long time, and suddenly it doesnât any more.
Also, the URL in the Postman is correct according to the documentation at https://developer.atlassian.com/cloud/confluence/rest/api-group-group/ (this links to âGroupsâ, which I am querying).
If there is another URL that we need to use, please document on this page as well (and all other related pages).
Note that API URL like https://acme.atlassian.net/wiki/rest/api/template/page 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:
https://api.atlassian.com/ex/confluence/{cloudid}/{api}
@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.
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.
Thanks,
Caterina
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.
Thanks,
Caterina
@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 api.atlassian.com format when accessing the affected API endpoints.
This is documented for âOAuth 2.0 (3LO) appsâ on the https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps 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 [CONFCLOUD-72411] Documentation pages incorrectly suggest to use the "your-domain.atlassian.net" instead of the "api.atlassian.net" one - Create and track feature requests for Atlassian products. 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,
Caterina
Hi @ccurti
Just to confirm, has the Base URL also changed from api.atlassian.com to api.atlassian.net ?
Thanks,
Sheetal
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 https://api.atlassian.com/ex/confluence/{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.
Thanks,
Caterina
Hello,
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,
Cheers
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 https://jira.atlassian.com/browse/CONFCLOUD-72411 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.