Greg-DB Dropbox Community Moderator

As in your previous thread, the UploadAsync method is for uploading a file (whether a new file or a new version of an existing file). If you want to rename an existing file you should use MoveV2Async instead. Additionally, if you want to duplicate, that is, make a copy of, an existing file, you can use CopyV2Async instead.…

I see you also opened a new thread for this, so I'll follow up with you there.

@"Acey1" It sounds like you're using the "Generate" button on the app's page on the App Console to create a new access token. Note that this now only creates "short-lived access tokens", which do expire after a short period of time. Also, note that if you leave or refresh that page, the previous access token will no longer…

Dropbox does offer an API you can use for listing, uploading, and downloading files, among other operations. You can find everything you need to get started with the Dropbox API, including documentation, tutorials, and SDKs here: https://www.dropbox.com/developers Specifically, to upload files, you can use /2/files/upload…

Thanks for the context. The underlying issue in this case may be different though. Also unfortunately sometimes request IDs are not sufficient (depending on the nature of the failure and some details of how the backend works). While we're looking into some errors on this endpoint we want to make sure we're identifying…

Yes, the PKCE flow in particular is a version of the OAuth 2 authorization flow that doesn't require the app secret, meant for client-side apps where an app secret can't be kept secret. It does so by using a 'code_challenge' on the /oauth2/authorize step and corresponding 'code_verifier' on the following /oauth2/token…

@"lizat" Здравко is correct, the Embedder documentation is the official reference for information on setting up and configuring the Embedder.

Thanks for the report! This looks like it may be a bug on our side. We'll look into it and I'll follow up here with any updates.

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…

We'll need to look into this further. Can you please open an API ticket and include: * Does it work successfully if you retry a failed call? * What's the affected app name or key? (Don't share any app secret, access token, or refresh token though.) * What account ID(s) are affected? Thanks in advance!

The UploadAsync method is for uploading a file (whether a new file or a new version of an existing file). If you want to rename an existing file you should use MoveV2Async instead. That takes a fromPath for the existing path (including file name) of the existing file to move or rename, and toPath for the new path…

This is the forum for the Dropbox API, but it sounds like your question is more about general software design, so it may be better suited in a general programming forum instead.

Yes, as you found, Dropbox is phasing out the ability to create new 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 token" that can be used to retrieve new short-lived access…

@"af11" Thanks for following up. I'm glad to hear you got that working. Your new question seems to be related to using Google to sign in to Dropbox, and the level of access used in that flow. We can only help with the Dropbox API itself here, so I recommend opening a thread in the accounts section of the forum or…

@"Robert S.138" Thanks for the feedback/idea! I can't make any promises myself, but feel free to open an API ticket if you'd like to request specific help/information.

Thanks for the additional information! We'll look into it and I'll follow up here once I have an update on this.

Thanks for following up. This file size limit has not changed recently. Uploading 1 Gb files in 8 Mb chunks is supported. To clarify, are you still seeing this issue on new requests now? And if so, is this occurring on all such requests, or only some of them? Also, if you can share a more specific date/time of when you…

@"Mark R.5" Thanks for the feedback. To clarify, I was not indicating that one would be required to update to an Objective-C SDK from late 2020. Rather, I was responding to Robert's specific question and confirming that such as version should be sufficient. I don't have specific versions of the Objective-C and .NET SDK to…

@"ephraimt" Yes, the current configuration is what we expect to serve going forward. That is, we are returning Content-Length on both HTTP/2 and HTTP/1.1 for these links, like we did originally. If this is currently not working for you, can you share the details of the current error you're seeing? Also, did this start…

There are a number of scenarios that can cause the refresh to fail like this, such as: * missing/incorrect/malformed refresh token * revoked refresh token (e.g., when the user unlinks the app via https://www.dropbox.com/account/connected_apps , etc.) * missing/incorrect/malformed app key * incorrect/malformed app secret *…

@"Robert S.138" Yes, Java SDK v3.1.5 is sufficient. And likewise a version of the Objective-C SDK from late 2020 would also be sufficient.

@"DreamingDev" 1. If you received that email it means your app sent some amount of TLS 1.0 or 1.1 traffic to the Dropbox API recently. If you’ve already updated your app, this traffic is likely coming from users still on an old version of your app. We don't have a way to simulate the change, but I'll pass this along as a…

Update: the team has been able to complete some further updates to our infrastructure to be able to support the previous non-chunked behavior going forward indefinitely. That means that we plan to continue returning Content-Length (and not 'Transfer-Encoding: chunked') in the future and will not be reverting this on 3/14.…

Update: the team has been able to complete some further updates to our infrastructure to be able to support the previous non-chunked behavior going forward indefinitely. That means that we plan to continue returning Content-Length (and not 'Transfer-Encoding: chunked') in the future and will not be reverting this as…

Update: the team has been able to complete some further updates to our infrastructure to be able to support the previous non-chunked behavior going forward indefinitely. That means that we plan to continue returning Content-Length (and not 'Transfer-Encoding: chunked') in the future and will not be reverting this as…

Update: the team has been able to complete some further updates to our infrastructure to be able to support the previous non-chunked behavior going forward indefinitely. That means that we plan to continue returning Content-Length (and not 'Transfer-Encoding: chunked') in the future and will not be reverting this as…

Update: the team has been able to complete some further updates to our infrastructure to be able to support the previous non-chunked behavior going forward indefinitely. That means that we plan to continue returning Content-Length (and not 'Transfer-Encoding: chunked') in the future and will not be reverting this on 3/14.…

Update: the team has been able to complete some further updates to our infrastructure to be able to support the previous non-chunked behavior going forward indefinitely. That means that we plan to continue returning Content-Length (and not 'Transfer-Encoding: chunked') in the future and will not be reverting this as…

Update: the team has been able to complete some further updates to our infrastructure to be able to support the previous non-chunked behavior going forward indefinitely. That means that we plan to continue returning Content-Length (and not ‘Transfer-Encoding: chunked’) in the future and will not be reverting this as…

Update: the team has been able to complete some further updates to our infrastructure to be able to support the previous non-chunked behavior going forward indefinitely. That means that we plan to continue returning Content-Length (and not 'Transfer-Encoding: chunked') in the future and will not be reverting this as…