Today we’re sharing an update on the existing v2-related requests that are currently marked as “Gathering interest”. At this time, we will not implement these requests before March 31 but may do so thereafter. If your app is dependent on any of these requests and you will not be able to fully migrate to v2 APIs by March 31, 2025, please contact us through developer support.
As a reminder, and as announced in https://developer.atlassian.com/cloud/confluence/changelog/#CHANGE-864 and https://developer.atlassian.com/cloud/confluence/changelog/#CHANGE-1116, the full list of v1 APIs being deprecated is available here
Do you have any estimated delivery schedule that you can share for the REST V.2 features that Atlassian is committing to deliver (the ones already marked: In Progress, Under Consideration, and Short Term Backlog)?
The deprecation date of March 31 is now seven weeks away, and once Atlassian delivers the above changes, vendors will still need time to implement and test. For planning purposes, it would be very helpful to understand what your timeline looks like, especially to help avoid a mad scramble at the end of the time period.
The REST V2 API is being removed from service in exactly one month. Atlassian has promised to deliver a number of issues before then, but seven of those issues are still open.
Are these issues still on track to be delivered? If so, when? If not, will the date be postponed again?
Our team has been working on addressing the remaining v2-related requests that we previously committed to. To date, we have closed all but 5 requests. The remaining 5 are in progress and we expect to complete them by the end of this month.
We understand that you will need time to adopt these changes and have decided to extend the deprecation until April 30, 2025. If you believe you will need additional time to migrate your apps to new v2 endpoints, please reach out to our developer support.
The changelog update for the new children and descendant APIs states that the corresponding v1 APIs will be retired on April 30, 2025, just like many of the other v1 APIs. Could you please confirm if this date is accurate? These APIs were not deprecated before and there hasn’t been a separate deprecation announcement in the changelog. I believe one month isn’t enough time to port apps to the new APIs.
As mentioned, the v2 endpoint /api/v2/pages/{pageId}/children and v1 endpoint /rest/api/content/{contentId}/descendant/page are not mentioned in the original deprecation notice for v1 endpoints, these have been flagged as deprecated just few days ago!.
Atlassian announced that deprecation notice until removal is at least 6 months. So please let us know when these 2 recently deprecated endpoints will be removed.
It is very unfortunate because we had made all the appropriate changes to our App, even deployed these changes to support the original v1 deprecation and now we discover that the v2 and v1 endpoints we used as replacement are now deprecated and seems that will be removed as well in 30 days!
Also, the changelog item that contains the deprecation info for the descendant endpoints is marked as Added. This makes it easy to overlook when filtering the changelog for the Deprecation Notice type. I suggest splitting this into two changelog items in the future - one of type Added and one of type Deprecation Notice. (But maybe this is just due to the fact that this was an attempt to sneak those into the original deprecation note. But I would never suggest that.)
Related to the the other devs scrambling to try to use the new V2 descendants APIs - I have filed ECOHELP-61173 to ask Atlassian to fix the OpenAPI spec to include _links so that it can be used to get subsequent cursors. I can’t share the ticket, but this is what I wrote:
Separate and apart from the issues related to the “timeline” (Update to Confluence v1 API Deprecation Timeline](Update to Confluence v1 API Deprecation Timeline - #25 by klaussner) ) for deprecating the V1 Descendants API, I’ve found that the API definitions in the OpenAPI spec are missing the key element _links.
In my experimentation, this property does exist, it’s just not documented in either your published OpenAPI spec, or your docs which I presume are built off of the spec.
The v2 descendants endpoint only fetches down 5 levels max and the results don’t contain an indication on which level a descendant is. Of course one could implement some evaluation of the parentId - id relationship and re-do the call for all level 5s or alternatively get level by level…
I also have to clue what the childPosition tells us…
Hi @klaussner,
I will respond on behalf of Laura as she is on leave at the moment. You are right that we did not give enough notice for these specific endpoints. To correct this, the retirement date for the deprecated v1 children and descendants APIs only will be extended until September 30, 2025. All other deprecated v1 APIs will still be retired on April 30, 2025. If you believe you will need additional time to migrate your apps to new v2 endpoints, please reach out to our developer support
Hi @LauraMehrkens, I’ve submitted a ticket CONFCLOUD-81134 requesting Atlassian to fix the GET v2 /spaces/{id}/pages API endpoint so it returns draft pages.
It would be super helpful if this could be fixed before V1 expires on April 30!
I agree. It is very important to know the descendant’s depth in the tree. Also, a maximum depth of 5 feels a bit restrictive, especially if we consider that the equivalent V1 endpoint had this limit at 100 (and another similar one had no limit at all).
It seems paradoxical, but despite all the proclamations and pressure, Atlassian itself hasn’t migrated its tools to the new APIs.
A few days ago, we started noticing some errors in our app, only to realise they weren’t caused by us but by Atlassian’s client SDK, which uses a deprecated endpoint.
Specifically, the AP.syncPropertyFromServer function we use to update properties in real time relies on the deprecated endpoint rest/api/content/<contentId>/property. See more: Confluence
Now, my concern is that this will be yet another unresolved bug, since Connect itself has been deprecated and probably no one is interested in fixing the issue anymore—leaving apps stuck in an intermediate migration phase missing yet another feature.
In the end, it’s always the customer who pays the price, facing a poor user experience.
Shouldn’t Atlassian be the first to set a good example by ensuring its SDKs are updated to the latest version of the APIs?
As I expected, the report was classified as a “suggestion” and not a bug. Which means it will probably end up forgotten along with many others.
In any case, if anyone else experiences the same issue or wants to upvote/follow its progress, here is the public link: https://jira.atlassian.com/browse/CONFCLOUD-81854