Hi @TylerBrown, In our app we need to have the space icon, so currently use the following expand to see that:
/wiki/rest/api/space/EX?expand=icon
But using the replacement:
/wiki/api/v2/spaces/:spaceId
It appears that space icon is not present, so is there a separate v2 API for that?
Or just like avatars, is there a URL I can build similar to:
https://instance.atlassian.net/wiki/aa-avatar/:accountId
e.g. maybe something like…
https://instance.atlassian.net/wiki/space-avatar/:spaceId
Hello,
I have posted my query here Unable to find page's tinyui, base and webui
But reposting here again, to gain attention.
I was using v1 rest API response’s following params, tinyui, base and webui, but unable to find these any more in v2 API’s response. Is there a way?
V1 API Response: /rest/api/content/{pageid}
{
"id":"734397355",
"type":"page",
"status":"current",
"title":"markdownPageUrlRelReplacementVars",
...
...
"_links":{
"editui":"/pages/resumedraft.action?draftId=734397355",
"webui":"/spaces/zmarkdown/pages/734397355/markdownPageUrlRelReplacementVars",
"context":"/wiki",
"self":"https://bobswift-prod.atlassian.net/wiki/rest/api/content/734397355",
"tinyui":"/x/qwPGKw",
"collection":"/rest/api/content",
"base":"https://xxxxxxx.atlassian.net/wiki"
}
}
Unable to find these any more in V2 API Response equivalent API: /api/v2/pages/{pageid}
{
"id":734397355,
"version":{
"number":2,
"message":"",
"minorEdit":false,
"authorId":"xxxxxxx",
"createdAt":"2023-03-29T09:24:13.587Z"
},
"parentIdString":"734396510",
"idString":"734397355",
"spaceIdString":"734396418",
"title":"markdownPageUrlRelReplacementVars",
"status":"CURRENT",
"body":{
},
"parentId":734396510,
"spaceId":734396418,
"createdAt":"2022-10-18T06:41:40.076Z",
"authorId":"xxxxxxx
}
Can someone please help?
Thank you
I have investigated which deprecated APIs we are using and what replacement there is for them. I have not yet investigated the performance impact of the new API.
There are a few API endpoints that I couldn’t find a replacement for:
children.* expansion. While there are APIs to retrieve custom content children of pages/blogposts/spaces, there is no API to retrieve custom content children of custom content. Also (not relevant for us) I noticed that there seems to be no API to retrieve child pages of pages.operations expansion on pages, blogposts, custom content and spaces. Do we need to run the Check content permissions API for each permission type, and is it performant to do so lots of times?permissions expansion for spaces.homepage expansion for spaces.I also noticed that the ?body-format=storage parameter for the /wiki/api/v2/*/{contentId}/versions parameter works but is not documented.
Can the v2 ‘get attachments’ endpoint please be updated to include the “fileId” field that is returned on the v1 data, and also the “_links.download” field which contains a URL.
V1 looks like:
While V2 looks like:
The “fileId” field is required when working with ADF content, for example here is the data of a ‘mediaSingle’ node representing an image:
The ‘id’ in the ADF attributes can be used to match the ‘fileId’ field on the v1 endpoint. Switching to the v2 api, no such matching is possible. After matching this we use the _links.download URL to get the ADF image to work when nested.
@candid For this use case, you can use GET /wiki/api/v2/spaces?keys=SPACEKEY, which works reasonably well.
But another missing API in v2 is an equivalent for the deprecated PUT /wiki/rest/api/content/{id} for attachments. You used to be able to use this to change the status of the attachment (current/trashed/deleted/historical), but there is no longer an equivalent in v2.
Hi Atlassian (@AlexWilliams @TylerBrown and others),
Could we please get some sort of public statement from Atlassian on your intentions for this deprecation? This was announced already a month ago, and in the meantime, the community has provided numerous examples of incomplete, broken (eg. ids as numbers), or completely-absent APIs. That leaves five months left for implementation (of which two months are in the summer, when many teams take vacation).
It would really help to have some guidance on the timeline (are you really sticking to six months from Feb even though no equivalent APIs are available yet?), as well as some feedback on how you are going to address all of the other issues.
In the case where you can’t commit yet to how you are going to address those issues, it would still help us by telling us, now, when you hope to give us that information, as well as any guesses about how you might fix the problems, and also telling us how all this will impact the timeline as a result.
Thanks!
Hi @scott.dudley ,
Thanks for checking in, sorry for the delayed response. We will be posting an update related to this and other changes on Monday.
Thank you!
Reporting a further issue I’m having where the Get Page endpoint documents a ‘version’ path parameter which results in a server error 500 when used.
This prevents us getting historical page version body content, which is important if you want macros to render correctly when the user is looking through the page history.
I did have a look at the “Get version details for page version” endpoint, which does work, but is not useful as it does not include the page body.
I’ve raised a support ticket for this, but noting it here also.
:NOTE: this is now fixed.
Hi @osiebenmarck - this should now be addressed in the changelog released here.
Hi Scott!
An update on the above, the changes that correspond to this changelog support the ability to:
We are still working on our Space Permissions API, but will release it as soon as we are able!
Hi all - it looks like I am limited to 3 replies so I will edit this last reply.
There are a number of things brought up in this post that have been addressed in the changelog here, please take a look!
Especially:
Create page endpoint now allows a parent page to be specifiedLink header is now also being returned in the body of the responseIn regards to things that are in the works:
In regards to JavaScript parsing issue - this was an oversight on our part and a fix is coming soon! The ticket here can be tracked as well: [CONFCLOUD-75484] Confluence Rest API v2 IDs are in int64 which cannot be safely represented in JavaScript - Create and track feature requests for Atlassian products.
@TonyGoughAdaptavist - sorry for the oversight! There was a fix for these recently merged, it will like be in production by the end of the week.
There is also a new post that announces a change to the deprecation timeline here.
Great to hear that!
Btw. do you also have any plans to provide a collection endpoint for all (transitive) descendant pages? With the current APIs (both V1 and V2) we need to recursively fetch the children of each page to get hold of the descendants tree.
Thanks!
@TonyGoughAdaptavist - sorry for the oversight! There was a fix for these recently merged, it will like be in production by the end of the week.
Whatever updates have been made have actually fixed a deeper issue for us.
Used to be, effort was required to have ‘older’ versions of our macros render as expected when the user was browsing older versions of a page in the Page History view. We had to manually get the historical page content and load historical versions of the macro that way.
I can see that this is no longer the case - our macros are rendering by themselves in the Page History view without that manual step, so they must now have the correct context data that they were lacking before. This means we no longer actually need the ‘version’ parameter.
However, I have tried using it anyway and can confirm that it is working 
Thanks @TonyGoughAdaptavist for sharing. I guess this apply to UI Kit right, and not CustomUI? As far as I have tested so far CustomUIs are still not supported for the export/print/history view.
@ErikUnemyr This is for Connect macros, I’m not sure how Forge ones are affected.
Hi Team,
Any updates to this query posted a week back is appreciated. Thanks
Hi Team,
Have you just removed xxxIdString fields from v2? If so, is v2 considered stable now? If not, how is the deprecation period for v1 set?
We migrated our code to v2 using those fields. It is broken before we release it and we have to change it to use different fields.
"parentIdString":"734396510",
"idString":"734397355",
"spaceIdString":"734396418",
Hi @jens - this is not currently planned but if there is enough of an ask for this we will get it prioritized!
Hi @TonyGoughAdaptavist - this is great to hear!
Hi @sunita - I don’t have an answer yet but will work on making sure someone looks at this soon. I can confirm this is present in V1 and not (at least yet) in V2.
Hi @eagle.xiao - I apologize for any confusion! To be transparent - we realized the issue with having non-string ID fields after release and decided to mitigate this issue by first adding equivalent string fields, like you saw. We then decided instead to expose a query param that would change the type of already existing fields, as recently announced in this changelog. This being said, the “idString” etc. fields were in production briefly before removing them and going the above route, which could have been confusing (our mistake here). Now, if you utilize the serialize-ids-as-strings param you should be good to use this to change the return type of the existing ID fields! Please let me know if we can help in any other way.
@SimonKliewer ,
After experimenting with the v2 API, I encounter a problem:
https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-content/#api-content-convert-ids-to-types-post returns the content type as a singular, e.g. page.
However the API to get page properties needs the plural in the route:
GET /wiki/api/v2/pages/{page-id}/properties
i.e. pages.
I think the API routes should use the same names as returned by the ID to type conversion. Otherwise all developers need a translation table to look up the right conversion, which makes our code error prone and seemingly a bit ad hoc.
Can that be changed?
And related to that, I think the v2 API should still be in beta until these kind of issues have been sorted out (and e.g. the IDs as strings issue).
The link you provided did not mention anything about the removal of idString fields. That is breaking change. Nobody knows whether it is “briefly” in production. It was IN production.