Over the air download via API fails today, worked yesterday.

Good news, this team worked on this, and was able to reduce the link length back to under 500 bytes. You should be able to request the shorter links again now. Please try it and let me know if you're still seeing any issues.

Please note, however, that the Dropbox API specification still does not guarantee a maximum length for this 'link' value. That being the case, please update your app(s) to accommodate a 'link' of arbitrary length (or at least, of significantly larger length).

I have also sent this along to the team as a feature request to codify a maximum length for the 'link' in the specification, however at this point I can't promise if that is something that will be done. The temporary link implementation on the Dropbox API backend is not trivial, and involves encoding certain authorization data in the link. The size of this data can vary.

Finally, an important security note:

Based on the context I've received around this issue, if I understand correctly, this is being used for updating devices over-the-air, by embedding pre-generated access tokens for a single specific Dropbox account directly in to the devices. The devices call a number of Dropbox API endpoints using that access token, such as /2/files/get_temporary_link (the result of which is used to download a firmware update payload).

The Dropbox API was designed with the intention that each user would link their own Dropbox account however, in order to interact with their own files. It is technically possible to connect to just one account as is being done here, but we don't recommend doing so, for various technical and security reasons, especially in client-side apps like this.

One of the main issues is that client-side apps can't keep secrets. A malicious user could extract the hard-coded access token from the app, and use it to access the Dropbox API directly to perform any operation (bypassing any access controls your app might have attempted to enforce). For instance, in this scenario, they could upload their own malicious payload, which would then be distributed to the other systems via the existing over-the-air update mechanism.

Of course, the actual difficulty to extract the access token and perform an attack depends on a variety of factors, and your organization can choose what level of risk you're willing to accept. Please contact a security professional for any general security advice.

For the above listed reasons though, I do not recommend using the Dropbox API in this manner. Instead, a typical CDN may be a better way to distribute updates. I've also sent this along as a feature request for a safe way to use the Dropbox API in this manner, but I likewise can't promise if this is something that would be implemented.