Greg-DB Dropbox Community Moderator

Also, unfortunately, API v2 doesn't support the file type permission, so you'll need to use a different one, as you found. I'll send this along as feedback as well.

1. Thanks for the feedback! We're hoping to address this better on our side in the future, but I don't have a timeline to offer right now. 2. That sounds like a bug. We're looking into it. 3. This is also planned, but likewise I don't have an ETA to offer. We really appreciate the feedback. I don't have a more specific…

Faris, if you just have the shared link to the file, you can't edit the file. If you have any further questions, please open your own thread instead of replying on this unrelated thread, so that we don't spam anyone else on it.

In that case, I recommend starting with the tutorial, which covers the basics, here: https://www.dropbox.com/developers/documentation/dotnet#tutorial

The DownloadAsync method can be used to download files, as you mentioned, but to find the paths of files, you can use ListFolderAsync. That will give you a ListFolderResult, which contains entries with paths. What have you tried so far, and what are you stuck on? Can you share any code and output that's giving you trouble?

1. No, API v2 doesn't return the v1 user ID. 2. For each user you have, with a known user ID and access token, use that user's access token to call /2/users/get_current_account and store the resulting account ID as being for that user.

Arusnundar, you can call /2/users/get_current_account for any given account using the account's access token and store the new account_id value from there.

API v1 isn't deprecated, so you can use it if you want, but we certainly recommend moving to API v2 when possible. For API v2, you should use the account ID, which is stable. As part of migrating to API v2, you should get the account IDs. I.e., for any access token, call the getAccount method to get the corresponding…

RTS, API v2 only uses the new account ID format, so we recommend moving to that if you're using API v2. You can use the getAccount method to get account information, including the account ID, from API v2 in the Java SDK. You can continue using API v1 methods if necessary though.

They're both globally unique, but the longer one from getAccountId is preferred in general, and is required when interacting with the API v2 calls themselves, e.g., when specifying a user.

These are just different formats for identifying Dropbox accounts. Is it causing any problems in your app?

The Dropbox API doesn't list any files that are still in the process of syncing, so you don't need to check if it's "fully synced". Any files available via the API, e.g., listed in /metadata or /delta, or accessible via /files (GET), are only the versions of the files that have been fully synced to the Dropbox servers. If…

Hi Paul, thanks for the feedback! Unfortunately, I don't believe there's a way to control the logging from the Sync SDK. Also, the Sync SDK isn't open source like the Core SDK is, but I'll be sure to pass this along as a request to make it open source.

Richard's correct, any links retrieved via the API count toward an account's link limits, just like any other links. If the content is just being accessed by your app directly though, you should use the file downloading API calls, which don't return links and thus aren't subject to those limits: v1:…

Thanks for the details Samantha! The Dropbox API Explorer is built for Dropbox API apps, not Dropbox Business API apps, and there is one additional thing that is required for Business apps like yours that the Explorer doesn't do. Specifically, when calling non-team endpoints, such as /users/get_current_account, you need to…

We definitely should improve the documentation around this. I've sent this along to the team to do so. I imagine there may be several use cases for retrieving metadata about a file it already has access to, e.g., if it doesn't know and needs to look up the original file path. Anyway, please give it a try, but I don't think…

I believe /sharing/get_shared_link_metadata also works for app folder apps, but only for links to items inside the app folder.

That blog post is about a Core API (a.k.a. API v1) endpoint that's unfortunately not implemented in the Python Core API SDK. You can instead use API v2, where the equivalent endpoint is /sharing/get_shared_link_metadata though. That's implemented in the Python API v2 SDK as the sharing_get_shared_link_metadata method.

It sounds like you're referring to the "authorization code", stored as `code` in the tutorial. The authorization code is temporary and can only be used once. The "access token", stored as `accessToken` in the tutorial, doesn't expire, so you can store and re-use that. When the user comes back, you can just retrieve that…

This is fixed in version 3.1.0.

We do have a fix for this ready, which will be included in the next release of the SDK. I don't have a date for the release yet though.

The sharing endpoints, as well as the SwiftyDropbox SDK itself, are no longer considered beta.The sharing methods in the SDK will get the updated documentation without the beta warning in the next SDK release. I don't have an update on this particular bug yet though.

Sorry, no update yet.

Thanks for the report! We're looking into it.

Quick follow up here, in the latest versions of SwiftyDropbox, upload/download request objects do now offer a `cancel` method you can call to cancel the request.

I don't believe the SwiftyDropbox SDK offers a way to cancel uploads, but I'll pass this along as a feature request.

Thanks! We'll look into it and follow up with you in your ticket.

Feel free to use a shared link to share the project. If you can reproduce the error with a manual request, e.g., using curl or something, that would be fine too.

That code looks fine, and I haven't been able to reproduce this unfortunately. That being the case, can you share a small sample project that reproduces this so we can look into it? You can send it via an API ticket if you'd prefer to share it privately: https://www.dropbox.com/developers/contact Thanks in advance! 

Can you share the code you're using to check the values? Also, when/where are you checking them? Maybe they're getting altered somewhere along the way. If you can share the output that may be helpful. Also, please share the rest of the code for the actual API call you're making.