Greg-DB Dropbox Community Moderator

Dropbox recently retired support for TLS 1.0 and 1.1. The Dropbox API servers now only support connections using TLS 1.2. You'll need to update your app/network client/environment to use TLS 1.2 in order to continue making Dropbox API calls. It looks like you're using the Dropbox Java SDK, so to use TLS 1.2 you'll need to…

The IList<UploadSessionFinishBatchResultEntry> Entries returned as UploadSessionFinishBatchResult.Entries from UploadSessionFinishBatchCheckAsync will be in the same order as the original IEnumerable<UploadSessionFinishArg> entries you passed to UploadSessionFinishBatchAsync, so you should refer to that original…

Dropbox is in the process of switching to only issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here. Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh…

This may be due to a recent change to our TLS configuration. Dropbox recently retired support for older versions of the TLS protocol, specifically 1.0 and 1.1. You'll need to make sure your app uses TLS 1.2. If you're using the Dropbox Python SDK, to use TLS 1.2 you'll need to update to at least v8.4.1 of that SDK (or…

When you retrieve a short-lived access token via /oauth2/token, the response includes the expiration information in the 'expires_in' field. You can store and refer to that information to check if the short-lived access token would be expired at any point in time. To actively check if any particular access token is still…

Are you referring to Dropbox shared links like "https://www.dropbox.com/s/..." or ""https://www.dropbox.com/sh/..."? The Dropbox API does offer an endpoint for retrieving the metadata for shared links like this: /2/sharing/get_shared_link_metadata. You can see the information it returns under the "RETURNS" section. Note…

@"RohanRaman" This is open with the team, but I can't guarantee a timeline for this change. You may wish to try following up with Google to inform them that this change is in progress but is out of your control to ask that they allow your app in the meantime.

The UploadSessionFinishBatchCheckAsync method returns UploadSessionFinishBatchJobStatus, and once UploadSessionFinishBatchJobStatus.IsComplete is true, you can use UploadSessionFinishBatchJobStatus.Complete to access UploadSessionFinishBatchJobStatus.Complete.Value which is UploadSessionFinishBatchResult, to access…

I just tried the code you shared, plugging in my own encoded app key and secret value, and I didn't get the error you're getting. Please double check that you're passing in only that base64-encoded app key/secret pair there after "Basic ". Make sure you don't have any other stray characters accidentally included. For…

You only need to do the authorization flow in the browser once per user. You can then store and re-use the resulting refresh token without further manual action. Refresh tokens can be re-used repeatedly and don't expire automatically.

First, for reference, if there are multiple changes at the same time in the same account or shared folder, you can run in to the 'too_many_write_operations' error, which is "lock contention". That's not explicit rate limiting, but rather a result of how Dropbox works on the back-end. This is a technical inability to make a…

@"RohanRaman" This is open with the team, but I don't have an update on it yet. I'll follow up here once I do.

You should implement the OAuth app authorization flow to get an access token, and optionally a refresh token. You can find information on that in the OAuth Guide and authorization documentation.

@"DrMDodd" For the official Dropbox API v2 .NET SDK in C#, you can find an example of getting and using a refresh token in the OauthBasic example (non-PKCE, meant for server-side apps) as well as in the OAuthPKCE example (PKCE, meant for client-side apps). As noted earlier in this thread, the SDK does not offer the ability…

@"marksmithhfx" Thanks for following up with the additional information. The "GET" and "POST" are referring to the HTTP "method" for the HTTP request. Every HTTP request uses one of a number of methods, for various different use cases, with GET and POST being two of the most commonly used ones. The Dropbox /oauth2/token…

@"marksmithhfx" Is that the exact code you're running? It looks correct, and it does work for me when I plug in my values. There may be something about how your client is formatting the request causing it to fail. Perhaps you can share the actual request/response you're getting (just redacting the sensitive values) so I…

@"RohanRaman" Thanks, that's helpful. I'm bringing this up with the right people to ask for that to be updated.

To get a refresh token, you'll need to use the OAuth app authorization flow. It is possible to process this in C#. For the official Dropbox API v2 .NET SDK in C#, you can find an example of getting and using a refresh token in the OauthBasic example (non-PKCE, meant for server-side apps) as well as in the OAuthPKCE example…

@"RohanRaman" Can you share the information they gave to you? For instance, the message they sent and any links/references to the "correct" branding? I'll send it along to the right people on our side. Thanks in advance! (You can also open an API ticket here if you'd prefer to share privately for whatever reason.)

@"Kase_Kuchen" Rich is correct, Dropbox webhooks are a way for third party applications to be notified of changes; they are not a way to create or access files. I recommend reading the Getting Started guide and File Access Guide first.

Dropbox is in the process of switching to only issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here. Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh…

For reference, the Dropbox API now also suppresses email notifications when using quiet=true on /2/sharing/add_file_member.

Thanks for following up. Please do let us know if you find anything else. Unfortunately since that endpoint does not expect anything in the request body, I believe attempting to send any such ****** data would cause the call to fail validation. And yes, in any case that we need to intentionally make a breaking change, such…

Thanks for the report! We'll look into it, but we could use a few more pieces of information: * Can you confirm that you are not using an official Dropbox SDK (such as the official Dropbox Objective-C or Swift SDK)? In that case, what network client are you using? * Can you share the relevant code snippet(s) for…

When you download file data from the Dropbox API, the API response will contain the requested data in the response body. Exactly what you do with that data, and how, is up to you and will depend on your environment. That's not part of the Dropbox API and is out of our control, so I can't tell you exactly what you can or…

Engineering is looking into it, but I don't have an update yet. I'll follow up here once I do.

@"TessaP" Здравко is correct, this is something that would need to be supported in rdrop2. You may need to reach out to the developer of rdrop2 for help or an update.

@"Steven_R" Здравко is correct. The 'token_access_type' parameter is only used on /oauth2/authorize, not /oauth2/token. This is unrelated to the app's access type (full Dropbox versus app folder).

1. Dropbox and the Dropbox API don't offer a concept of sharing with an application exactly; sharing takes place across accounts. For example, a user can share a folder with another user. A user can authorize an app to access their account though, which would give the app (as long as it has the "Full Dropbox" access type)…

Yes, it sounds like you have the right handle on this now. For the Dropbox API calls themselves, they should either return a result, or raise some sort of exception (such as an API error, or some network error, etc.). They shouldn't fail silently. It seems that the issue with them failing silently was due to the thread…