Greg-DB Dropbox Community Moderator

That file is not inside a shared folder. It is only individually shared. That's a different kind of sharing, and so sharing_info won't be returned for it.

@"1PoC1" I don't have an update on this request to share. I'll follow up here if/when I do.

I see you're using the Xamarin.Dropbox.Api which is not an official Dropbox SDK. It's owned by Microsoft and Xamarin. That would need to be updated for the new authorization functionality. It looks like it hasn't been updated since 2017 though, so you may want to contact them to see if they will update it.

@"sahir" I don't have anything to add on the Dropbox side. The Dropbox API still offers both of these pieces of functionality, so it would be up to Zapier to update their implementation.

Yes, those are optional so you can set them to nil, except for "accessToken", but it looks like you can just set that to an empty string, assuming you're using the standard authorization functionality such as authorizeFromControllerV2 and authorizedClient which will take care of that for you.

Thanks for letting us know about the broken docs page! I'll ask the team to fix that up. Anyway, the equivalent of setting that custom identifier in the SwiftyDropbox SDK would be to set the "userAgent" parameter when making a "DropboxTransportClient", like seen here.

While you can plug in an access token for your own account like you showed here, the API was designed with the intention that each user would link their own Dropbox account, in order to interact with their own files. That's accomplished by implementing the OAuth flow in your app, so that each user can authorize the app to…

The same tokenRevoke method can be used with the new short-lived access tokens as well. Calling it will revoke the short-lived access token used, as well as the corresponding refresh token and other short-lived access tokens for that refresh token, if any. Just performing an access token refresh does not invalidate…

If you don't specify "scope", it will default to requesting the set of scopes enabled for your app (on the App Console) at the time of authorization.

No, the authorization functionality for Android in the Java SDK automatically requests "offline" access (i.e., to retrieve a refresh token), and doesn't offer the ability to configure that. I'll pass this along as a feature request, but I can't promise if or when that might be implemented. (For reference, the DbxWebAuth…

The sharing_info field is optional, meaning that it will not always be returned. The sharing_info field is documented as: sharing_info FileSharingInfo? Set if this file is contained in a shared folder. This field is optional. So, since there is no sharing_info in this result, that indicates that this file is not in a…

The file request listing functionality doesn't return new updates to file requests that have already been listed like this. If you want to get the latest information about a file request, you should call /2/file_requests/get for a particular file request, or start from /2/file_requests/list_v2 again to list all of the file…

@"mukund" Unfortunately I don't have more specific information to share as to when 'owner_display_names' should or shouldn't be expected in the response. I'll send this along to the team to request more specific documentation on that, but I can't promise if/when that would be updated.

The error from the Dropbox API here "Error in call to API function "files/search": request body: missing required field 'query'" indicates that the call was rejected because it did not include the required parameter "query". From the code you shared though, I see you are setting the "query" parameter for the "filesSearch"…

Dropbox does offer an API you can use for listing, uploading, and downloading files, among other operations. You can find everything you need to get started with the Dropbox API, including documentation, tutorials, and SDKs here: https://www.dropbox.com/developers You may want to check out the Getting Started guide:…

That's correct, you don't need to call refreshAccessToken yourself. As long as you set things up as instructed, the SDK will handle all of that for you. And yes, as long as nothing specifically happens to invalidate the refresh token (such as the user unlinking the app, deleting their account, etc.) the refresh token will…

There isn't a big difference here. By setting the "-1L" expiration that makes the SDK immediately perform a refresh regardless of the actual expiration. The SDK will still handle the refresh process as/when needed though in either case, as long as the necessary pieces are given. (For PKCE, it only really needs the refresh…

The /2/files/list_folder and /2/files/list_folder/continue endpoints do not restrict you to listing files that have changed since a certain date (nor do they offer date filters exactly). They can be used to list the full contents under any path, such as a specific folder or the root folder (identified by the empty string…

@"alextanalextan" It's also worth noting that if you just want to access the contents of team folders/spaces, you don't actually need to add "team" scopes to your app. An app with the individual user scopes, such as files.content.read, can be connected to Business and non-Business accounts alike. You don't need…

I'm closing this as a duplicate of this thread.

Could you share the relevant code you're using and output you're getting so we can look at what you're seeing specifically? Thanks in advance!

@"HuS" Yes, I believe this is still the case. This feature request is still open with the team, but I don't have any updates on it.

The number of entries you get back per page is not guaranteed, and it may require multiples calls even if there is not a large number of entries. You'll need to implement both list_folder and list_folder/continue and always call back for more entries until has_more is false in order to get the full listing.

Long-lived access tokens are now considered deprecated, but we don't currently have a plan to disable existing long-lived access tokens. (If that changes, we will of course announce that ahead of time.) That being the case, you can continue using existing long-lived access token(s). Note though that after the change you…

There are a number of different variables that will effect the overall performance, such as where the data is located, as well other things like network routes and conditions, etc.

No, unfortunately there isn't another option for this that would be faster, but I'll pass this along as a request to improve the performance. I can't promise if or when that might be done though.

Is there anything on your network connection that may be interfering with connections to dropbox.com or dropboxapi.com, such as a firewall, proxy, anti-virus, etc.? Otherwise, I'll be happy to look into this further, but I'll need some more information. In that case, please reply with: * the name and version number of the…

Unfortunately there isn't really a good way to do this via the Dropbox API, but I'll pass this along as a feature request. I can't promise if or when that might be implemented though. Currently, you could retrieve the video data via /2/files/download, but you'd need to pass that through your server anyway to avoid exposing…

@"HuS" If existing solutions don't address your use case, you can certainly build your own integration. To get the original/full size image data, you could use /2/files/download.

If you're using a long-lived access token (e.g., as you described, by setting the "Access token expiration" setting in the App Console to "No Expiration" and then using the "Generate" button to generate an access token for your account and app), then you don't also need a refresh token. (Refresh tokens are for use with…