Oh JFC. I had to search for your previous posts on here to verify that. Scott is correct; replies from Atlassian staff confirming it’s in beta and not available for Connect apps.
The GraphQL docs make zero mention of being unavailable for Connect apps. And the official v2 API blog post suggests using the GraphQL API as an alternative for removing expansions.
Who do we need to escalate this to internally? I’ll take this to Mike and Scott if need be. I’ve already spoken casually to many long-time employees who’ve all agreed this is a poor transition strategy.
At the absolute minimum this deadline must be extended for at least another 12 months (and not Jan 1st ffs). I remember you guys started this v2 API by deploying broken IDs into prod where you switched strings for ints which were too long for JSON to parse correctly. Each time a new endpoint is released or a new gap/flaw is discovered, the migration deadline (if truly necessary) should be extended another 12 months.
Is the real reason for this access cutoff down to infra costs? v1 and v2 are running in prod in parallel now, so it can’t be a technical issue. Jira API has no issues serving both v2 and v3. If it is due to overhead costs then I’ve already outlined a suggestion on how to properly transition.
If this goes ahead I can foresee a substantial percentage of broken apps on the marketplace come Jan 1st, with cascading business impacts for vendors and customers.
Because any developer that migrates now is doing so knowing that the v2 API is still incomplete (just search “upcoming” in this thread). And any developer who rationally leaves this migration until Nov/Dec is highly likely to find missing data parity, and will need to roll the dice on Atlassian fixing that gap before the deadline.
Given that it takes 2 weeks to get a reply to a support ticket and the access cutoff date is stupidly set during a global holiday period, that’s a huge business risk.
And that is why you’re noticing intensifying anger from vendors on the forums. They know they need to action this unnecessary rework on an inferior and incomplete v2 API within the next 1-2 months.
Thanks, @SimonKliewer. Endpoints like that would be really helpful. Ideally, we could get the number of children and descendants for a page (we are currently using CQL for that) and also for multiple pages at once (similar to the id parameter of the “get pages” endpoint).
Thank you everyone for your feedback! We greatly appreciate your inputs.
Firstly, we would like to express our gratitude to all the vendors who have already migrated to v2. We hope that you are experiencing the advantages of more granular and performant APIs. We are thrilled to introduce even more new endpoints to you as we introduce new content types in Confluence. Additionally, we are working on updating all Atlassian apps to use the v2 APIs.
We would like to take this opportunity to assure you that we are actively working on addressing every feedback item that we have received in previous community posts and as part of this RFC. We have created CONFCLOUD tickets for the feedback that was shared in the past and is currently in the RFC.
We understand that it can be difficult for you to identify all deprecated APIs used in your code. Fortunately, we have this information available and would like to offer you a one-time snapshot of all deprecated APIs used by your apps. To receive this information, please raise a Developer Support ticket and share your app key with us. We would be happy to provide you with a list of all the deprecated APIs currently being used by your apps.
We know that the holiday season can be a busy time for everyone, which is why we have extended the deprecation of all APIs until January 31st, 2024. We want to assure you that we are committed to following our policy as outlined in Atlassian’s REST API policy on time frames. If there are any gaps for a specific API endpoint, rest assured that we will only deprecate that endpoint six months after achieving parity for that endpoint. At the same time, we kindly request that you continue updating your apps to use v2 APIs as soon as possible so you can take advantage of their benefits.
Future Feedback: If you come across any gaps in REST API v2 in the future, please report them to Developer Support. Use the “Bug” request type and be sure to mention that gap is related to the v1 deprecation. We will actively work on resolving any blockers. This process is more transparent and your report will be added to the tickets queue. Going forward, we will not be monitoring the developer community for additional v2 feature gaps posts.
We appreciate all of you for working with us! Thank you so much for all your input and contributions that will make this a success!
