Ditto to some degree. And there’s no endpoint in v2 to simply fetch content by ID. So I guess we’d just need to hit blogposts/{id} and pages/{id} and go with whichever one returns a 200 response. Genius.
I wonder if anyone at Atlassian intends to address the fundamental flaws discovered in this thread or just steamroll on. The inability to JSON.parse IDs is the most hilarious one so far. I’ve pinged that to many internal Atlassian’s who’ve had a good laugh at that one.
I was thinking the same. Or use V1 search.
V1 search isn’t a foolproof functional replacement due to its “eventual consistency” nature. If you’re doing fast CRUD operations, you can’t necessarily expect search to be always caught up. This is especially the case if you’re (say) creating things from the back end, and then expecting to immediately see the same data from the front end. (I guess the requests end up on different database servers?) I once heard informally that the expectation for consistency was max 15 seconds, but I haven’t seen this published anywhere.
Hi Nathan,
We appreciate your feedback. I can assure you there is no intention here to steamroll on and ignore feedback.
The team has been hard at work since this post was announced. We have been taking into consideration every piece of feedback posted here, as well as going over many tickets we have received.
We have already addressed a majority of feedback items received here and plan to release them in bulk next week.
We apologize for the misstep with the ids as strings, we were well aware of the issue with javascript ints, but when it came to the type used here we had it as a string and then accidentally changed it at one point as part of another refactor. This is one of the items that will be addressed next week with the addition of an id string field, and then a sufficient deprecation period.
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 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.
Hi Team,
Any updates to this query posted a week back is appreciated. Thanks