Comments
-
You could use the Dropbox API to list files and folders without having the desktop client installed, e.g., using API v2 /files/list_folder. However, the API doesn't currently offer any sort of file hash or checksum. I'll send this along as a feature request though.
-
This isn't currently possible, but I'll send this along as a feature request.
-
There certainly shouldn't be anything on our side causing this. If the API was going to intentionally fail a request, it would respond with an actual HTTP error code, but -1001 is just a client side error code. The best practice is to only download files if/when you need them, but if you do need to download many files, the…
-
There isn't any particular limit on our side around 172 files. The -1001 error code corresponds to NSURLErrorTimedOut though, which can happen for a variety of reasons, e.g., if the network connection fails, or if your connection is too congested. How many simultaneous connections are you allowing? I've seen other…
-
How are you downloading the file when it does work? Are you using the Dropbox web site? Can you compare the file you get that way to the file you get via the API? E.g., compare the file lengths and/or hashes. Some other things that would be helpful in debugging this: - the rest of the relevant code (e.g., what do you do…
-
Hi David, apologies that the documentation and explorer aren't clear on how to use that. I'll send that along as feedback to get that fixed up. I'm glad to see you sorted this out already though.
-
This should return an error as expected now.
-
No update on this yet. I'll follow up here when this is resolved.
-
Thanks for the report! We're looking into it.
-
Alexander, it sounds like you already sorted some of this out, so I'll follow up on the latest thread you replied on, so as not to spam others on these threads.
-
Apologies for the inconvenience! The API v2 shared link endpoint doesn't return all of the same information. I've sent this along as a request but I can't offer a timeline for when it may be added to v2.
-
Hi Tim, unfortunately that endpoint in API v2 doesn't currently return those particular pieces of information, but I'll be sure to pass this along as a feature request.
-
The /2/sharing/get_folder_metadata endpoint you're referring to is for operating on shared folders, but you have a shared link (to a folder) which is a different kind of sharing functionality on Dropbox and so uses a different ID. If you want information about a shared link, for a file or folder, you can use…
-
We changed it to not respect the period in a query, e.g., so if you just search for ".mov" the results will include "test.mov" but not "not a movie file.txt".
-
Hi Matias, quick update: searching by file extension should be working now.
-
Thanks for the feedback Matias! The team is aware of these differences and difficulties with search in API v2 versus v1 and hopes to address them in the future. I can't offer a timeline for when improvements may be available though. I've included your feedback as feature requests for the various improvements to API v2…
-
To close the loop here, this was fixed in version 0.7.1.
-
Thanks! I can reproduce this. We'll look into it.
-
What version of the SDK are you using? If it's not up to date, please update it and let us know if you're still seeing this. Thanks!
-
The redirect_uri being supplied in that /authorize URL is: "urn:ietf:wg:oauth:2.0:oob". That doesn't start with https://, and as such isn't allowed by Dropbox's OAuth 2 implementation, per the error message. You'll need to use an https:// (or localhost) redirect URI instead. If it's helpful for your case, Dropbox provides…
-
Hi Fábio, can you elaborate on the issue you're seeing? It sounds like you are properly seeing the error message on the /authorize page. OAuth 2 redirect URIs for the "code" flow do need to start with "https://", unless it's a localhost address.
-
Ok, the /authorize page should be behaving properly now, and returning useful error messages. For example, in this case, you should get: "More details for developers Invalid redirect_uri: "x-agent://dropbox_callback": When response_type=code, redirect_uri must start with "https://", unless it's a localhost URI."
-
Thanks for the report. We're looking into it.
-
For client-side apps like this, you should generally use the OAuth 2 "token" flow. You can find more information in the documentation for /oauth2/authorize: https://www.dropbox.com/developers/documentation/http/documentation For the redirect URI, you can either use a local address that your app will listen on, or if you're…
-
Thanks for the additional information. Based on those version numbers, you are indeed using the Sync SDK in both cases. I'm afraid Dropbox can't offer any further support or bug fix releases for it, per the timeline in the blog post. The change log is here though, in case the information is useful:…
-
Hi Francis, to clarify, what version of the SDK do you have, and what do you mean specifically when you say it "doesn't even get past the first Dropbox call" on the latest one? Based on your code snippet, it sounds like you're using the deprecated Sync SDK, which is no longer supported:…
-
Hi Sam, this seems to work for me: $ curl -X POST https://api.dropboxapi.com/2/sharing/list_shared_links \ > --header "Authorization: Bearer ACCESS_TOKEN_REDACTED" \ > --header "Content-Type: application/json" \ > --data "{}" { "links": [ {redacted for brevity} ], "has_more": true, "cursor": "eyJwcm9nIjogIjE0N{redacted for…
-
This should be fixed now in version 2.2.0. Thanks for the report!
-
While in development mode, Dropbox Business API apps can only be linked to a single team, as noted here: https://www.dropbox.com/developers/documentation/http/teams#production The error you're getting indicates that the app has already been linked to a team, and so can't be linked to another one.
-
Unfortunately, it's not currently possible to limit this (the length depends on the amount of information it needs to encode, which will vary by account). I'll send this along as feedback though.