Please can we have more warning about REST API changes


I was pleased to read this morning as I’ve asked loudly for in the past.

However, I’m struggling to understand why Atlassian cannot give vendors more than 1 weekend’s notice of the changes? My team and I have other work commitments today and have regular life plans over the weekend, so we’re not going to be able to make the necessary changes to our Cloud products in order to keep the product working correctly.

@aagrawal2 Please can you delay the rollout of this change for at least another 7 days?



I had similar thoughts (well not about Jon’s weekend plans).

While I don’t have functionality relying on this particular thing - I am consuming Jira api‘s and this is a slippery slope. “Fixing” the error code like this is updating the rest api. Will we discover that next week that somebody decided that there was an error in the entity body where the spelling of color should have been colour?

I appreciate that this might be a bug - but if you’re having to updating the documentation - then you’re changing described behavior…


I’d like to strongly reinforce the message here, not because we have functionality affected by this change, but because we do have several apps (for Confluence in our case) that rely on specific behaviors of the REST APIs (some documented but some not) that are clearly API design defects or even legitimate bugs for which “fixes” would now constitute breakages in the public contract on which we’ve come to rely.

Given how frequently we’re forced to react to platform changes by several different Atlassian teams, any API changes that are not backward compatible really deserve a much longer change notice period, if not either an opt-in mechanism to the new behavior or an outright deprecation and replacement with a new API. As a small dev team, we simply don’t have the bandwidth to drop everything we are doing (which is often reacting to some other Atlassian team’s change of course) and immediately respond to announcements like this.



I realize Cloud and Server completely are different platforms, but the software development goals are ultimately the same: making tools that give customers joy.

The Atlassian Server platform teams provide a lot of support the Cloud platform teams do not. This seems to be more cultural than technical or even from being understaffed.

This topic is one small example but with a big impact.

I think everyone would be happier if the Cloud teams could close the ecosystem support gap a little bit. Including but not limited to a bit more advanced notice AND testing that their changes may break functionality customers are relying on.

Not to be unnecessarily dramatic but we’ve recently learned some of our customers use both Atlassian’s and our tools for timely medical support. You can extrapolate what that could mean and I urge you to do so.

We are not looking for perfection, at least I’m not. Just an acknowledgement that Atlassian is considering and communicating ways to improve not pushing breaking changes to our customers. Apologies if I’ve missed that acknowledgment.


@jbevan and others, we’ll engage with the Jira Cloud team re: an extension on this change.


Hello everyone. So, we’ve been engaged with the prod/eng team, and the new change date for this API method (introducing the 409 error code) has been moved to May 4, 2020. The blog post has been updated to reflect this date change.


Thanks very much @nmansilla

Any updates on this…it’s way past May 4th. : )

No it’s not, Atlassian operates under a GMT-404 hours (and yes, although coincidental, the update not found error code pun is definitely intended)