Greg-DB Dropbox Community Moderator

@"terryz" Thanks for clarifying. Yes, that error would indicate something went wrong with the transfer, but it sounds like curl was able to recover and complete the download successfully. It may have just been a transient network issue. Regardless, it doesn't appear to reproduce the original 400 error code from your…

@"terryz" I see you are getting the two expected 302 responses, and then the final successful 200 response. When you say it fails, are you referring to the "schannel: failed to decrypt data, need more data" message? That doesn't occur for me, and I do get the expected 6848 bytes of data saved out when I try. Does the file…

@"Здравко" Thanks for the note. Yes, that would require the use of some server-side component.

@"terryz" You can run the curl example I shared in my earlier comment to see how the requests are formatted. (There are some redirects involved, but curl will handle that automatically since "-L" is specified.)

@"Gcleanwood" The API was designed with the intention that each user would link their own Dropbox account, in order to interact with their own files. As Здравко mentioned, while it is technically possible to always connect to just one account for all users, we do not officially support this, for various technical and…

You can delete an app itself without losing the data in the connected account(s). Deleting an app registration does not delete the corresponding app folder(s) or the data contained within them. It would only prevent further API calls for the app from succeeding. You can also rename or move the app folder or the parent…

@"terryz" The HTTP GET method is correct for this scenario. It's often the default for HTTP clients, so even when you don't specify it, clients will usually use GET automatically.

@"terryz" Thanks for sharing that, though unfortunately I don't think that we'd be able to determine the issue from that; a 400 like this should generally indicate that there was something incorrect about the HTTP request, but the request data would be encrypted in that capture so we couldn't read it anyway. Perhaps…

@"Goldmine" Using the options.path parameter on /2/files/search_v2 is the right way to restrict the search to a particular folder. (By the way, the API v2 Explorer can be useful for trying out calls like this.) I just tried that and it is working for me. If that doesn't appear to be working for you, please share the code…

@"magnafire" Thanks for the feedback! I've added your note to the feature request.

Using /2/sharing/get_shared_link_metadata is still the right way to get metadata from a shared link, and that now supports both User Authentication (using an access token, as before) as well as App Authentication (using an app key and secret instead of an access token). If that works better for your use case now, I suggest…

There isn't a specific period you should use when polling a job status like this, but in general just a few seconds would be reasonable, say 1-3 seconds between calls to check. If you know it's a particularly large job and may take longer, you might want to make that a little longer. If any particular job fails, the result…

Thanks for the report. It looks like this occurs when the user's account does not have its email verified. I'll ask the team to fix up that error reporting. You should be able to resolve this by verifying the email address on the account.

One reason for the search results being different across users is if the users have different contents in their accounts, e.g., if the relevant items are not currently mounted in an affected user's account. I see you also open a support ticket for this though, so we'll review this specifically for you and follow up with…

No, the "rev" value, e.g., as returned by /2/files/list_folder[/continue], is an opaque revision identifier. It can be used for a strict equality check with other rev values, but it's not meant to be modified, and shouldn't be used to attempt to determine if a rev is older or newer than another. For information on how to…

This should be fixed now. Please let us know if you're still seeing any issues.

This should be fixed now. Please let us know if you're still seeing any issues.

This should be fixed now. Please let us know if you're still seeing any issues.

This should be fixed now. Please let us know if you're still seeing any issues.

This should be fixed now. Please let us know if you're still seeing any issues.

This should be fixed now. Please let us know if you're still seeing any issues.

Thanks for following up. I'm glad to hear you already got the Dropbox Embedder working. To allow users to upload files to your account, check out the "file requests" feature.

The "spatie/dropbox-api" library isn't made by Dropbox, so we can't provide support for using that library in particular. I recommend referring to the documentation and support resources for that for help using it. For reference, the Dropbox API itself allows apps to download files using the /2/files/download endpoint,…

@"olavolsf" As Здравко said, a 'path/not_found' error doesn't indicate an issue with the access/refresh token itself. If an access token or refresh token is invalid, attempting to use it will fail with an error indicating an issue with the token. A 'path/not_found' error indicates an issue with the 'path' value being…

@"3d_Schorsch" In addition to the information Здравко helpfully provided, if you're interested in using Dropbox's OpenID Connect support for authentication for your site, be sure to read our OpenID Connect Guide.

The Dropbox API has a general rate limiting system that applies to all account types; there isn't a plan available for purchase that would circumvent that system. Apps should be written to handle these rate limit responses automatically. Also note that not all responses with a 429 or 503 status code indicate explicit rate…

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

@"dbxlab" Thanks for the samples! This does appear to be the same issue. This is still open with engineering and I'll follow up here once I have an update on this.

When you say you executed it, it sounds like you're referring to the step where you call /oauth2/token to exchange the authorization code for a refresh token and access token. It looks you're sending the parameters as JSON though, but the /oauth2/token endpoint requires application/x-www-form-urlencoded POST parameters,…

Thanks for the report. It looks like the .NET SDK is unnecessarily retrying (repeatedly, with a backoff) on 'expired_access_token' failures. I'll ask the team to update it to skip the automatic retries on that kind of failure. To work around this, you can make a DropboxClientConfig with maxRetriesOnError set to 0, and pass…