Hi there,
We are currently using the following endpoint in our app:
https://developer.atlassian.com/cloud/confluence/rest/v1/api-group-space/#api-wiki-rest-api-space-spacekey-content-get
To make the REST call, we utilize several expand options to retrieve the necessary information for our app to function. The query looks like this:
/wiki/rest/api/space/${spaceObject.key}/content/page?expand=space,ancestors,children.page,version.number,permissions,metadata.properties.emoji_title_published&limit=100
Since we have to migrate to V2 due to deprecation, do you have any advice or suggestions for us? I couldn’t find any information regarding similar query parameters in the documentation for the new endpoint:
https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-page/#api-spaces-id-pages-get
I remember your interesting talk about REST V2 at Berlin App Week. Do you have any advice for us, @TylerBrown ? 
Will there be a mapping table available for migrating from V1 to V2? Also, is it possible to retrieve the information we currently fetch in V1 using GraphQL?
Thank you in advance!
Martin
1 Like
Hi @MartinKistnerDecadis! Thanks for the feedback here. We are looking for feedback on the fields app developers are using in order to make sure we are supporting them in V2. Not all fields from V1 are yet present in V2.
Would it be possible for you to play around the V2 endpoints and note which fields in particular you need from V1 that are not present in V2? We can then get that work prioritized. Thanks so much!
Hi @SimonKliewer,
so our app currently based on a space Key renders all the pages of these spaces and shows them within a tree. I assume you would also advise us to move to this endpoint:
GET /wiki/api/v2/spaces/{id}/pages
We are currently expanding the old endpoint by the following fields which would be must-haves for us before deprecation or we need to rewrite:
- space
- ancestors
- children.page
- version.number
- permissions
- metadata.properties.emoji_title_published
So maybe to have some kind of expectation management for us from your side:
Do you expect us to:
a) query multiple endpoints and maybe rewrite (bigger) parts of our app to somehow get the same information available on v2?
b) you will take care of making it possible to retrieve the same information we currently get on V1 to be available on v2 and would provide time to migrate to v2? (because as far as I see it the deprecation period is already set but you are not providing the same information on the new rest entry points at least today)
The final question will you deprecate v1 endpoints before the same information is available on v2?
Thank you very much in advance and as well for your quick response!
PS: Is there a preliminary list of what fields are available which is maybe not yet documented?
2 Likes
Hi @MartinKistnerDecadis! Thank you for your thorough response and my apologies for the delayed follow up.
The answer is a combination of the 2 - the V2 APIs are are more tightly coupled to the entity they are designed to return for the reasons outlined here. We understand that in some cases, this will mean that more requests will be required than were before.
That being said - we intend to make all information needed from V1 available in V2, in order to set developers up for a successful migration. We are seeking out any blockers developers might have, and are prioritizing / unblocking as quickly as we can.
For example, let me know if the following endpoints would work for what you have listed: space, ancestors, children.page, version.number (should be returned as part of page response entity), permissions.
The emoji_title_published is a content property that can be fetched with the content property endpoints.
Hopefully this helps! Are there any other blockers we can with?