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.
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.
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.
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.
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.
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'
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.
@ccurti
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 (api.atlassian.com)?
If it works, it’s a completely “undocumented feature”. The 3LO documentation makes it clear to use the api.atlassian.com 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.
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
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.
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 https://api.atlassian.com 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).