Atlassian has introduced scoped api tokens to restrict which apps (like Confluence, JIRA, etc) a token can access AND what the token can do. However, when issuing rest calls with the scoped token, the preamble form of the url changes so that the whole call now looks like https://api.atlassian.com/ex/confluence/<your_cloud_id>/wiki/rest/api/
To get the cloud ID, this community forum post lists the following call:
However documentation suggests there is another method where the user has a “back and forth” interaction to get the cloud ID which is not preferable to the tennat_info endpoint.
This ticket is to make all necessary adjustments to enable Scoped tokens.
Supporting both Scoped and UnScoped tokens across the whole API presents a challenge. To support across the whole API I’d have to edit the “Login from INI” front and back end. That is, when the user creates a new token I’d have to present the option for the type of token they would create (which means they would need to understand the difference). AND once the user makes the selection from my UI, I cannot force them to actually create the scoped vs unscoped token in Atlassian’s ui (risking the user telling the API one thing, but doing another). Further, the format of the login.ini file would become more complicated because it would have to support both a Scoped and UnScoped token per email address. I would want a single email address to be able to list an instance of both for one email address.
Adding complexity to the API, UIs, and Login.ini is possible but, in my opinion, isn’t worth the frustration.
So I’m making the decision to support Scoped Tokens ONLY through the Construct call vs using the Login.ini file. that is