Community resources
Community resources
Community resources
Archived or deleted? Settling a missing Jira Release in one REST call
Someone tells you a Release has vanished. It was there last week, it isn't on the Releases page now, and they want to know whether it was archived or deleted.
The Releases page is a bad place to answer that. Not because it's broken, but because it filters. An archived version is deliberately hidden from the default view, so "I can't see it" and "it doesn't exist" look identical from there. You end up clicking through filter dropdowns trying to prove a negative.
The REST API doesn't filter. That's the whole trick.
One call that settles it
GET /rest/api/2/project/YOURKEY/versions
That returns every version on the project, archived ones included, and each one carries an "archived" flag:
{ "id": "10420", "name": "1.4.0", "archived": true, "released": true }
{ "id": "10421", "name": "1.5.0", "archived": false, "released": false }
I didn't take this from the docs and hope for the best. I tested it on my own instance, Jira Data Center 11.3, before trusting it: created a version, archived it through the UI, called the endpoint again. It still came back, with "archived": true.
Reading the answer
The result splits the problem in two, and that's more useful than it first sounds.
The version appears in the response. Then it was archived, not deleted. Nothing is lost, and the only thing between the reporter and their Release is the Releases page hiding it.
The version does not appear at all. Then it wasn't archived, it was deleted. Stop looking for it in version lists and go to the audit log instead. This matters because archiving and deleting a version write different events. If you search the log for the wrong one you will conclude nothing happened.
That second branch is the part people skip. It is tempting to keep hunting the UI for a version that no longer exists.
Bringing it back
If it is archived and you want it live again, you do not need the UI at all:
PUT /rest/api/2/version/10420
{"archived": false}
That returned 200 for me and the version came straight out of the archive. "archived" is one of the fields this endpoint accepts, alongside name, released, releaseDate and the rest, so the same call is how you would flip release state in bulk.
The one thing that will trip you up
The id in that PUT is the numeric version id from the GET response, 10420, not the version name.
This is worth calling out because of how it fails. Passing the name does not give you a clear "no such version" - you get a 404 or a 400 depending on what you sent, and it reads like a permissions or endpoint problem rather than a wrong identifier. People go off and check their token. Copy the id out of the GET response and you are done.
Run the GET first anyway, even when you are confident the version is archived. It costs one call, and it is the difference between "I unarchived the right thing" and "I sent a PUT to a version id I guessed."
Why bother when the UI can do it
It can, once you know the version still exists. The value here is the order of operations. The API answers archived-or-deleted before you have spent any time in filter dropdowns, and it answers it in a form you can paste into a ticket. When someone escalates a missing Release, "here is the API response showing it archived, here is the call that restored it" closes the conversation faster than a screenshot of a filtered page.
It also scales. One missing Release is a UI job. Thirty of them after a migration is a loop over the GET response.
Worth knowing
Whoever runs these calls needs permission to browse the project, and administer-project rights for the PUT. If the GET returns an empty array on a project you can see has versions, suspect permissions before you suspect the endpoint.
I tested on Jira DC 11.3. These endpoints are long-standing and I would expect the same behaviour across current DC versions, but if you are on something much older it is worth the same thirty-second check I did: create a version, archive it, call the endpoint.
If you would rather do this from ScriptRunner than curl, the same two endpoints work fine from a script. Test the unarchive on a throwaway version first rather than on the one someone is waiting for.
Ran into this from the other direction, a Release you could not account for or an audit log event that did not match what you expected? I would be interested to hear how it turned out.
I am an IT and Jira administrator working with Jira Data Center, ScriptRunner and JSM.