Hello,
In the deprecation notice of */download/attachments/* internal API’s: https://developer.atlassian.com/changelog/#CHANGE-2735 the recommended action is to migrate to the public Attachment API
These APIs return a download link to the attachments that are in the format of e.g.:
"downloadLink": "/download/attachments/4554781/Screenshot%202021-04-23%20at%2010.49.16.png?version=1&modificationDate=1619419837134&cacheVersion=1&api=v2",
Just wanted to clarify if that downloadLink format will be deprecated as well?
Best regards
Miika
2 Likes
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).
jens
August 25, 2025, 4:51pm
3
Hi,
I had created an ECOHELP ticket concerning this ~2w ago and back then Atlassian said:
This deprecation announcement applies specifically to PAT token usage. This will not longer be supported. Session usage like using the download link within the page’s content or marketplace app usage which is JWT usage will still function appropriately. Hope that this clarity helps.
I asked them to update the changelog accordingly, but apparently that hasn’t happened
Cheers,
2 Likes
Great, I also created a ecohelp ticket and just yesterday got the response
The development team confirmed that the requests made with JWT auth and user impersonation requests should continue to function as expected.
@jens @MiikaMkiniemi Thank you for sharing this! Seems odd, though, to only apply this to PATs. And “forgetting” to mention that. Looks like the first step in a direction. Curious to see what’s next.
Just to be really really sure - does this deprecation affect download links that look like this (as returned by the v2 attachments endpoint):
/download/attachments/87031809/CSharp%20Web%20Template%20-%20Contact.aspx?version=1&modificationDate=1715882016295&cacheVersion=1&api=v2"
Does the file name count as ID ?
If yes , the link would indeed match the deprecated pattern /download/attachments/{id}/{id}.
If no , then those links should not be deprecated, right?
My understanding (and hopefully someone can correct me if I’m wrong) is that the deprecation is for calls using a personal access token (API calls), and does not affect session based calls (someone logged in, and downloading an attachment).
I don’t know if that helps answer your question though.
I’ve got scenarios where those /download/attachment/{id}/{filename} links are used in conjunction with personal access tokens, to download files.
If those endpoints are affected, I need to switch to this v1 API instead (I guess): https://developer.atlassian.com/cloud/confluence/rest/v1/api-group-content---attachments/#api-wiki-rest-api-content-id-child-attachment-attachmentid-download-get
Given a page ID and attachment ID, above endpoint redirects to the file download URL.
I’m just not sure if this is really required.
