Greg-DB Dropbox Community Moderator

Every API call for uploading or downloading to/from a Dropbox account requires an access token for that account. You can easily generate an access token for your own account, but to get them for other users of your app, you'll need to send them through the OAuth app authorization flow. We have an OAuth guide here that…

You should poll MembersAddJobStatusGetAsync after MembersAddAsync to get the result.

Thanks! It looks like you were using both the Core SDK and the Sync SDK. They both use API v1, so you'll want to replace both of them with a single API v2 SDK. The new API v2 SDKs are built more like the Core SDKs, giving you direct access to the API calls for uploading and downloading files, among other operations. You'll…

That isn't part of the public Dropbox API, which doesn't currently offer a bulk thumbnails call, but I'll be sure to pass this along as a feature request.

This thread was about getting temporary links in bulk, and didn't mention thumbnails. I see you've posted a new thread about this so I'll follow up there: https://www.dropboxforum.com/t5/API-support/Getting-multiple-thumbnails-of-multiple-files-at-once/m-p/191818#M8428

The /redirect_receiver page you're using is just a blank page on dropbox.com for receiving the redirect. You'll want to send the user elsewhere or just close the browser after that, depending on what you want your app to do.

No, upgrading your account doesn't affect the operation of your API app.

The Swift 3 branch has the DropboxClient constructor just taking the access token as a string now, but the Swift 2.3 branch still requires a DropboxAccessToken object there. You can construct it like this: DropboxClient.init(accessToken: DropboxAccessToken(accessToken:"ACCESS_TOKEN_HERE", uid:"USER_ID_HERE"))

No problem, and yes, it looks like you have this right. 1. No, you'll just need to poll occasionally. 2. The complete result from finish batch itself is actually not currently used, and is just there for flexibility in the future. We may update that in the future to use that result and include the metadata there, but for…

Yes, in that case you would end up sending an empty chunk, but that won't make any difference in the resulting file. And yes, using the finish batch method is the best way to commit multiple files at the same time without causing lock contention with yourself. And that's correct, the strategy you described is reccomended…

For that sample, you should add "https://localhost/authorize" as a redirect URI for your app on the App Console: https://www.dropbox.com/developers/apps

The start and append methods don't return space errors. Only the finish calls do, as that's when the final file size is known and checked against the available quota space when attempting to commit the file. 

The parent_shared_folder_id field will contain the shared folder ID for the shared folder that contains the item, regardless of how many levels up that is. If you want the immediate parent of an item, whether or not it is the shared folder itself, you can ****** the last element off of the item's path_lower. Using that…

That method doesn't offer a way to request a short URL, but I'll be sure to pass this along as a feature request. (The only place this is available in API v2 is createSharedLink, but that is deprecated.)

Can you elaborate on what you mean when you say you can't catch the access token? What specifically isn't working?

No, unfortunately I don't have an update on this.

The 5 MB chunk size is somewhat arbitrary, and up to the app. The best size would depend on various factors. When the connection is reliable, larger chunk sizes mean better overall performance. If there are connection errors, smaller chunk sizes means you have to retransmit fewer bytes when requests do fail. You may want…

1. That's correct, since overwrite is NO, destinationURL will be the same as downloadURL. (The documentation is a little misleading due to an old reference to "closure". We'll get that fixed up.) 2. and 3. These methods have these modifications to avoid some reserved keyword/prefix constraints in Objective-C/Cocoa. It's…

Yea, I don't believe the API v2 Objective-C SDK stores the app key in the credential store/keychain like the API v1 Core SDK does.

Hi Keith, for reference, yes, in API v1 it was also possible to just overwrite a file without a rev. In either though, it's generally not reccomended, as its easy to overwrite data you didn't intend to due to race conditions that way. 1. That's correct, with autorename set to NO, the API won't attempt to find somewhere to…

Thanks! That error indicates that the app key is missing. Make sure you filled in the DropboxAppKey and DropboxAppSecret values in Web.config for that sample app.

Did you get the sample running and try it out? Where did you get stuck exactly? Also, we have an OAuth guide here that should serve as a good primer for how the flow works: https://www.dropbox.com/developers/reference/oauthguide

Hi Jackson, this endpoint isn't time based exactly; when you supply a path it acts as a sort of filter on the events you'll get back. Suffice to say though, the behavior you described is expected, and the best way to handle that case would be file ID support for /files/list_folder, so I'm sending this along as a request…

I don't believe we have a good sample of that for the Objective-C SDK in particular, but I'll be sure to pass this along as a request for one. There's a sample for the Swift SDK here, which may be useful though:…

I see, thanks for pointing that out!

That's correct.

Can you elaborate a bit on your use case and usage of these timestamps? I'll be happy to pass it along as feedback to the team. Even on API v1, the "modified" time for a folder didn't reflect changes inside that folder, so I wouldn't expect it to be very useful for caching.

This isn't available in API v2, but I'll be sure to pass this along as a feature request.

Yes, API v2's "pathDisplay" is the same as API v1's "path", so the last path component (only) is guaranteed to have the expected casing.

I see, if you're looking for that case in particular, in API v2 lock contention is now a 429 with a structured too_many_write_operations error. In the SDK that should be a DBAUTHRateLimitError with a TooManyWriteOperations DBAUTHRateLimitReason.