Thanks for following up. I see you're referring to the links returned by the /2/files/get_temporary_link endpoint. Per the Dropbox API spec, the returned GetTemporaryLinkResult.link field is only documented as String without a more specific format/domain guaranteed. The exact link format/domain used may vary over time as the Dropbox implementation is updated and maintained, but the link returned should always be valid for four hours.
The implementation for that endpoint has been recently updated, for instance, to return links with a different domain and format, but the returned links are still valid. Specifically, the new format contains a "#" at the end of the link. Per the HTTP spec, the "#" is a reserved character for identifying the beginning of the "fragment" portion in a URI.
One thing we're seeing, however, is that some HTTPS client handle the "#" in the URL incorrectly. HTTPS clients are not supposed to include that portion in requests to the server, but some clients mistakenly do. If that is the issue, you can work around this by removing that trailing "#" from the end of the link before passing it to your client. (Be sure to do so in a fail-safe manner though; the Dropbox API spec does not guarantee its presence, so make sure your code wouldn't fail if it isn't present to begin with.)
I understand you are not able to deploy such an update however, because this is the mechanism you would use to do so anyway. That being the case, I'm raising this with engineering to see if we can accommodate this somehow on our side, though I can't make any promises right now. I'll follow up here with any updates on that.
