Greg-DB Dropbox Community Moderator

Thanks for following up. I can't offer any details on the implementation of the Dropbox Android app itself, but I'll follow up with any updates on the reports you linked to.

@"Diegovsky" Thanks for the feedback! For reference, not all of the functionality used in the Dropbox product itself is available via the API, but I'll pass this along to the team. In addition to Здравко's guidance, be sure to check out the File Access Guide and Detecting Changes Guide, if you haven't already.

Apologies for the delay; it appears your thread was only recently moved to this section of the forum. This error indicates that the app/user is being rate limited. The Dropbox API does have a rate limiting system, and if/when a particular connection might be rate limited depends on a number of factors, which can vary over…

It sounds like this may be because we recently updated the server back-end for some types of Dropbox links to use "Transfer-Encoding: chunked" (and accordingly not return the "Content-Length" response header) on HTTP/1.1. HTTP clients should automatically handle this, but it's possible yours doesn't. Are you able to…

Thanks for the report! We'll look into it.

Thanks for the report. I'll raise this with the team again. And yes, v5.0.0 was the last version before v5.1.0, where Java source and target compatibility was bumped to 11. The team applies updates to the SDK to the most recent version, but I'll pass this along as a request for support on older versions as well. I can't…

Здравко is correct, while the creation of new long-lived access tokens is now deprecated, we don't currently have a plan to disable existing long-lived access tokens. (If that changes, we will of course announce that ahead of time.) That being the case, you can continue using existing long-lived access token(s) without…

That's correct, you'll need to check the list and filter based on the desired name. Shared folder names are not unique identifiers, so it's possible for there to be more than one for any particular name. That being the case, it's not possible to look up a specific single shared folder just based on a name. And yes, you…

Yes, as long as you implement the authorization flow as shown, the SwiftyDropbox SDK will automatically handle the refresh process for you in the background, without any further manual user interaction required. If something isn't working as expected, please show the steps you're following when seeing the issue and the…

By default, Dropbox API access tokens for your app(s) don't become invalid and yield 'invalid_access_token' by themselves, but there a number of different ways that a Dropbox API access token can become invalid, including:* the user or team admin can revoke all access tokens for an app by unlinking it on any of the…

You can find a working example of getting and using a refresh token to maintain long-term access with the .NET SDK here: https://github.com/dropbox/dropbox-sdk-dotnet/blob/main/dropbox-sdk-dotnet/Examples/OauthBasic/Program.cs That example shows how you can explicitly call RefreshAccessToken, but that's actually not…

The output here doesn't seem to mention any Dropbox code. Do you get any other error/output/stack containing any Dropbox SDK references? Also, can you elaborate on what you mean when you say you were "upgrading my code to the latest editions"? What specifically were you upgrading (for example, the Dropbox SDK itself, or…

Yes, that update was deployed towards the end of January.

Thanks for following up. I'm glad to hear you got this working. I can't provide guidance on what other headers you should or shouldn't be setting though, as that depends on how the app works and what the app does.

That's correct, the ListMountableFoldersAsync method in the .NET SDK returns a ListFoldersResult with Entries being a list of SharedFolderMetadata. There's a SharedFolderMetadata.Name property that you can use to get the shared folder name.

Thanks for the additional information. So, it looks like the "corrupted" download has an extra 13 bytes of data, which some zip utilities tolerate and which some don't. Based on this, it looks like this is because your client isn't properly decoding the HTTP message. We recently updated the server back-end for these links…

Dropbox doesn't offer a pre-built component like that for deleting files, but I'll pass this along as a feature request. I can't promise if or when that might be implemented though. You could use the Dropbox Chooser to have the user select file(s) though, at which point the app would then receive the corresponding file…

Thanks! I'll pass this along as a feature request, though I can't promise if or when that might be implemented.

We can help transfer API app ownership. Open a ticket here from the account that currently owns the app to get that started: https://www.dropbox.com/developers/contact

Can you try inspecting the corrupt download to see what the issue is specifically? For example, compare it to the original file to see why it does not appear to be a valid zip file. Also, note that curl's "-I" doesn't actually download the file, so that may not be a useful test. Here's how you should actually do this with…

With the API v2 JavaScript SDK, you can make a copy of a file using the filesCopyV2 method.

That's correct, you can't add members to non-shared folders. The folder will need to be shared (e.g., via /2/sharing/share_folder) so that it will have a shared folder ID before you can add members.

Apologies for the confusion. It looks like that was supposed to be "Dropbox-API-Select-User" instead. Please try that out and let me know if that doesn't work for your use case.

Can you clarify what you mean when you say the file is corrupted? What is in the downloaded file? For example, is it empty, or missing data, longer than expected, etc? Also, note that the "-I" option on curl only performs a HEAD request, meaning it only requests the headers, so it won't return the actual file data to…

There isn't another link type that I can refer you to that won't necessarily use this transfer encoding. "Transfer-Encoding: chunked" is part of the HTTP spec so I can't guarantee it won't be used for any particular URL. You should update your client to support this, and/or HTTP/2.

No, we don't have specific documentation on this for the Dropbox API, but I'll pass this along as a request. I can't promise if or when that might be added though.

I'm not aware of any reason off hand that .m4a should works but .ogg wouldn't. Note that using Postman may not be representative of your actual video player client on Android though, as they may use different HTTP versions or features. Are you able to get any logging output for the actual client on Android?

I understand you're programmatically accessing Dropbox shared links, and have been relying on the "Content-Length" header being set on responses. Please note that Dropbox does not guarantee that the "Content-Length" HTTP response header will always be present on the responses for these URLs though. For example, when the…

Dropbox still doesn't support wildcards in OAuth 2 redirect URIs. One workaround to this is to instead use one static redirect URI (say, on a particular non-changing domain you control), but encode the necessary information (such as the changing domain) in the 'state' parameter, and decode it as necessary after the…

Thanks, in that case if the 500 isn't coming from Dropbox itself, this may be because we recently updated the server back-end for these links to use "Transfer-Encoding: chunked" (and accordingly not return the "Content-Length" response header) on HTTP/1.1. HTTP clients should automatically handle this, but it's possible…