Deprecation of /download/attachments/ APIs

I’m wondering this as well. The downloadLink cannot really be deprecated, can’t it? How would we download an attachment then?

Maybe the {id} part of /download/attachments/{id}/{id} really just refers to IDs (not filenames)?

Clarification on that is needed.

And for the record, because sometimes those deprecation notices change, here the current notice:

We are announcing the deprecation of the following internal API endpoints:

  • /download/attachments/{id}/crash-scraper/files/{id}

  • /download/attachments/{id}/{id}/customer-card-payment-rest

  • /download/attachments/{id}/{id}

  • /download/attachments/{id}/{id}/{id}

  • /download/download/attachments/{id}/{id}

  • /download/attachments/{id}/{id}/{id}/{id}

  • /download/attachments/{id}/attachments/{id}/{id}/{id}

  • /download/attachments/{id}/{id}/image

  • /download/all_attachments

Key Dates:

  • Deprecation announcement: August 6, 2025

  • Removal date: November 6, 2025

Why is this happening?

  • This API is not intended public use and is not supported.

What will happen?

  • On and after the removal date, all requests to the listed endpoints will fail.

Action Required

EDIT:

One thought - the change might be related to new data security policies that Atlassian is introducing, which can be used to prevent files from being downloaded.

Found another thread about how to download files via OAuth (which failed via downloadLink), that points to the following v1 API as solution → https://developer.atlassian.com/cloud/confluence/rest/v1/api-group-content---attachments/#api-wiki-rest-api-content-id-child-attachment-attachmentid-download-get

The pattern of that API is /attachment/{attachmentId}/download, which is not included in the deprecated pattern list. And the v1 endpoint is not deprecated (yet).