Greg-DB Dropbox Community Moderator

Unfortunately, there isn't currently a good solution here. After you move/rename a file, listing the revisions at the new path won't show the old revisions. As a workaround though, you can call to list the revisions at the previous path, and they will still be there.

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

Thanks for the request ID volkeru! That one happens to be a different issue than the one originally reported on this this thread, but it is also a known issue we're working on.

No update on this unfortunately.

I don't believe we have any examples quite like that for the API v2 Java SDK, but I'll be happy to help with any issues you're running in to. The basic idea is that you can call listFolder and listFolderContinue initially until hasMore is false to get the initial state. Then, you can listFolderContinue for the relevant…

No, no update on this right now. I can't promise if that would work as a workaround, as each case may be different, but it may help.

To follow up here, if you do need to migrate OAuth 1 access tokens and want to do so via API v2, we now have an API v2 endpoint for doing so: https://www.dropbox.com/developers/documentation/http/documentation#auth-token-from_oauth1

To follow up here, we do now have an API v2 version of this: https://www.dropbox.com/developers/documentation/http/documentation#auth-token-from_oauth1

No problem, that would look like this: [DropboxClientsManager setupWithAppKey:@"APP_KEY"]; DBTransportClient *transportClient = [[DBTransportClient alloc] initWithAccessToken:nil selectUser:nil baseHosts:nil userAgent:nil backgroundSessionId:nil delegateQueue:nil appKey:@"APP_KEY" appSecret:@"APP_SECRET"];…

Thanks for the additional information! I can't reproduce this issue using your code though, so it does seem there's something else going on. I took a closer look at the output you shared, and the PAC/proxy messages cite error 1022, which is NSURLErrorAppTransportSecurityRequiresSecureConnection. That indicates it is the…

The other output seems to indicate that you may be trying to use a proxy, configured via a pac file. Is the pac file hosted on HTTP? Otherwise, can you share the rest of the code? What you shared was incomplete. I'll be happy to try to reproduce it.

The Dropbox API operates entirely over HTTPS, so it shouldn't trigger a message like that. Are you sure that's the only thing running when you get this?

Thanks! We'll look into it.

That is the right way to do this, but it looks like the curl example in the documentation for /2/auth/token/from_oauth1 is unfortunately incorrect. I'll let the team know to fix that. That endpoint actually uses app authentication, so an OAuth 2 access token isn't necessary. This is what the curl example should look like:…

If the file isn't found, your catch block should get run, with the data variable containing the error information. Is that not running for you?

Thanks for the report! This is a known issue, but I don't have a timeline for a fix right now.

Yes, it sounds like you want the /2/team/members/get_info endpoint: https://www.dropbox.com/developers/documentation/http/teams#team-members-get_info That lets you look up one or more team members by suppling any of team_member_id, external_id, or email.

Hi Joel, a server exception like this indicates an issue on our side. These are usually transient, so you can just have your app retry these calls. It looks like we did have a spike of errors earlier today, but that should be resolved now. If you are able to reliably reproduce any of these though, please share the steps to…

When using the Business API, the rate limiting for the team endpoints are similarly per-team, not per app. For the user endpoints, it is per-team member. We don't have any specific numbers available though.

Thanks! We'll take a look and respond to your ticket soon.

Thanks for the feedback! As it is designed the format of the response is not dictated by the format of the request, but rather can be determined programmatically by checking the response Content-Type. I'll send this feedback along to the team though.

The level of access an application has is decided by the developer when they first create and develop the app. That level of access is described when you first choose whether or not to connect the app to your app, as well as after the fact, on your account security page. You can see the level of access for each app…

If authorizedClient is nil, that would be why your app doesn't seem to "remember" the user. That's presumably related to the crash you're getting. Perhaps the app is crashing before the access token is being stored. Can you step through in the debugger to at least see where the crash is occurring?

Thanks for the feedback! The 400 error here with the plain text error message is more meant for the developer during development of the app. Generally, your app should be written such that a malformed access token like that wouldn't be able to make it into your released app, but you can catch the 400 and display the error…

The app shouldn't be crashing without some sort of error. Can you double check the console in Xcode?

Thanks for the report! The 500 response to an invalid access token would just be a bug on our side. We'll look into it The 400 is expected if the supplied string doesn't match the expected pattern for an access token, for example when supplying "abc" as mentioned. You can check the response body for an error message: Error…

The canOpenURL error would just indicate that the application being looked for (i.e., the official Dropbox app in this case) isn't found. That's expected on the simulator, or on a device without the official device installed. This error is safe to ignore, as the SDK will fall back to using the browser. Can you share the…

Did you follow all of the instructions for setting up the app authorization flow? https://github.com/dropbox/dropbox-sdk-obj-c#handling-the-authorization-flow If so, what error(s) are you getting? A few notes from what you shared so far though: * In API v2, the Dropbox root folder is identified by the empty string "", not…

That is the right pod name, but have you run `pod setup` yet? Try that if you haven't. If you have, try `pod repo update`.

It looks like there are some potential solutions here, if you haven't already seen these: https://github.com/Carthage/Carthage/issues/1135 https://stackoverflow.com/questions/32772573/project-name-was-compiled-with-optimization-stepping-may-behave-oddly-varia If those don't help, feel free to open a ticket with the…