Greg-DB Dropbox Community Moderator

If you have a shared link and want to download from it using the Objective-C SDK, you should use the getSharedLinkFile methods.

I can't seem to reproduce that error. Can you let me know what versions of Carthage and Xcode you're using? (`carthage version` and `xcodebuild -version`) Thanks!

No, the Dropbox API doesn't offer anything quite like that, but I'll pass this along as a feature request.

If you haven't already, please open an API ticket so we can look into why you're getting double webhook notifications. In any case, even without that issue, it's possible for users to trigger multiple webhook notifications in quick succession, so this is something you should build your app to handle. There's guidance on…

Thanks! That's helpful. It looks like curl is waiting for the request body. Since this API call doesn't require one, you need to tell curl that, like this: curl_easy_setopt(curl, CURLOPT_POST, 1L); curl_easy_setopt(curl, CURLOPT_POSTFIELDSIZE, 0); Or, you can send the JSON "null" in the body instead: headers =…

It sounds like you're referring to the following threads: https://github.com/dropbox/dropbox-sdk-js/issues/172 https://www.dropboxforum.com/t5/API-support/Thumbnails/m-p/263451 Did you try including the library as a JavaScript library instead of a Node dependency? Can you elaborate on how exactly the fixes failed for you?

The output you shared is from the response. Can you inspect the request itself?

No, Dropbox doesn't offer anything like that, but I'll be sure to pass this along as a feature request.

Thanks for the additional information. Since this is affecting all accounts, and the same endpoint works when using curl directly on the command line, it sounds like this is specific to how it's being called in your script using the curl lib API. Can you share that script that has the issue so we can use it to reproduce…

I don't see anything clearly wrong here. (We recommend not disabling SSL verification though.) Anyway, it's possible to get that generic 4xx error if the HTTP request itself is malformed. For example, perhaps $token is leaking an invalid value into the Authorization header. Can you check that it is the access token string…

I don't believe we have an example for using file_get_contents. In any case, when you get an error from the API, such as a 400 response, the best first step is to check the response body, which should contain a more useful error. Anyway, it looks like you have a newer thread, so I'll follow up there:…

Thanks for the feedback! I'll send it along to the team.

Thanks for writing this up. I can't make any promises, but I'll ask the team to clarify the API error responses in these cases.

Are you seeing this for all accounts, or does this only seem to affect specific account(s)? If it's only affecting specific ones, please open an API ticket and share the account IDs for reference. Also, does the call eventually time out, and if so, what output do you get? Thanks in advance! 

The upload endpoints, such as /2/files/upload, do now allow you to explicitly set `client_modified` when uploading a new version of a file. For reference, do you need to be able to do so without uploading a new version?

Thanks! That's correct, that error message indicates that the request body (containing the API call parameters) wasn't valid JSON as required. Looking at your code, that seems likely, as I don't see where you're building it as JSON, and the code you're calling presumably doesn't default to returning JSON. You should update…

We recommend just using the official .NET SDK, so we don't have a sample for doing this directly. Anyway, the error information you shared is just the status code/line. The response body should contain a more useful error message. Checking the response body is generally the best first step in debugging these. Can you print…

For API v2, the first step for debugging failures like this is also to check the content of the response body. It should contain a more useful error message. Can you share the response body? Also, since this is likely related to how the request body is formatted, please share a sample of that as well. Thanks in advance!

I can't say offhand unfortunately. If you'd like us to look into it, we'll need more information. Please open a ticket as requested in my previous reply if you'd like us to do so.

To list files in a folder, you should use /2/files/list_folder and /2/files/list_folder/continue. To download files, you should use /2/files/download. If an API call fails, the response will contain an error. What response body are you getting back?

I just tried this, and it is working properly for me. Are you still seeing this issue? If so, is there anything on your network connection, such as a firewall or proxy, that may be interfering? By the way, I redacted it from your post, but for the sake of security, you should disable that access token. You can do so by…

If the shared folder is mounted in the account of the connected user: - to list the contents, it is best to use /2/files/list_folder (supplying the `path` value), and /2/files/list_folder/continue, if necessary. - the download file data, it is best to use /2/files/download. (Using /2/files/get_temporary_link would also…

The SDKs don't offer the option to disable the use of the official Dropbox app for the app authorization flow, but I'll pass this along as a feature request.

Apologies for not following up on this sooner. I just wanted to update this to let you know we now officially document which file types give which preview type: https://dropbox.github.io/dropbox-sdk-java/api-docs/v3.0.x/com/dropbox/core/v2/files/DbxUserFilesRequests.html#getPreview-java.lang.String-

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

Can you double check that there are still entries to list in the relevant account, e.g., via the web site? Make sure you didn't accidentally delete the contents in the Dropbox folder (or in the relevant app folder, if you're using an app with the "app folder" permission). If there are definitely active entries that should…

We don't have a public feature request tracker, but I'll follow up here if/when I have any news on this.

The user limit doesn't apply to production apps, so it sounds like you may accidentally be using a different app key. Can you double check which one you're using against your app registrations on the App Console? If you need help tracking that down, or if you're definitely using your production app key, please open an API…

If you need to list all entries, included nested files and folders, you should use files_list_folder and files_list_folder_continue. You can do so by setting recursive=True on the initial call to files_list_folder. The Dropbox API doesn't offer a way to automatically retrieve the file extension, so you should extract that…

It looks like you're trying to use the old API v1 Sync SDK for Android. That does use API v1, so API calls made by it will fail now. I don't have an example available of exactly how they would fail though. (The Sync SDK had some offline and retrying functionality built in, so the failure may not be immediately obvious…