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_attachmentsKey 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
- We recommend migrating to the public Attachment API before the removal date.
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).