Greg-DB Dropbox Community Moderator

@"tuiren" Thanks for the feedback! I'll pass this along to the team.

Thanks for following up. If you can collect some more details from the affected users, that may be helpful. For instance, it may be helpful to know: * do the failures occur a specific amount of time? (as that may indicate a specific timeout) * are they using a particular browser? * are they in a particular region or using…

I don't believe we have a full example for that exactly, but I have a post here that may be helpful.

The Dropbox .NET SDK examples happen to use a listener, but the authorization flow itself also supports custom URL schemes when using PKCE. In any case, the Dropbox .NET SDK is not built for or tested with Xamarin/Maui/iOS in particular. I'll pass this along as a feature request for official support for that, but I can't…

This is the expected behavior; the team_data.member scope has a dependency on the team_data.governance.write scope so the team_data.governance.write scope is required if/when you enable the team_data.member scope.

I'm not aware of any changes that should be causing failures like that. Do you have any error/logging output to share regarding this issue? Also, how long do the connections run before they fail?

@"phunction" As Здравко said, you can omit the redirect URI entirely, in which case the user will be presented with the authorization code directly so they can manually copy/paste it into the app. Otherwise, to use a redirect URI if you can't use a server, you can use a redirect URI with a custom URL scheme for your app,…

It looks like you're sending the parameters as JSON, but the /oauth2/token endpoint expects them as application/x-www-form-urlencoded POST parameters, and so your parameters aren't getting read. Update your implementation to send application/x-www-form-urlencoded POST parameters instead.

Check the contents of the response body for that error response. It should contain a more specific error message.

[Cross-linking for reference: https://stackoverflow.com/questions/77624842/dropbox-webhooks-getting-team-related-response-instead-of-file-related-informati ] @"dhavalsoni" Based on the sample you shared, I see that your app is "team-linked", and so is receiving team webhook notifications. You can find the documentation for…

Unfortunately I can't promise if or when the scope information will be included in the public API responses.

@"jonokivex" Unfortunately I don't have a timeline to offer. I'll follow up here once I have any news on that.

Dropbox now returns "short-lived" access tokens, which automatically expire after a few hours. Dropbox is no longer offering the option for creating new long-lived access tokens. Dropbox is now issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information…

Thanks for the report! That issue with using "rlkey" links in the Embedder is open with the team. I'll follow up here once I have an update on that. The Embedder does not offer an option for viewing nested images inside the Embedder instead of in a new tab, but I'll pass this along as a feature request. I can't promise if…

It looks like this is more about iOS and its interaction with local servers/Xamarin, as opposed to the Dropbox API itself. You may be better served by referring to resources about iOS or Xamarin for help with this. For instance, I found this thread which may be helpful.

Are you only seeing this reported by one customer? This issue doesn't reproduce for me, even when using the same request body sizes, and I'm not seeing any other reports of this error. I'm not aware of any issues on the Dropbox side that should be causing this. Is there anything on the customer's network connection, such…

Please open an API ticket so you can privately share the full response you're getting from that endpoint. We'll be happy to then use that to check on that for you specifically.

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

@"whats" The SwiftyDropbox SDK doesn't offer a way to print out the raw HTTP request/response, but you should be able to check the `error` for any given call, e.g., as shown in the `response` handler in the examples 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. While it is technically possible to always connect to just one account for all users, we do not officially support this, for various technical and security reasons.

It's not possible to skip the app authorization flow and gain access to the end-user's account. In order for the app to access the user's account, the user needs to grant the app access to their account. This only needs to be done manually once per app-account pair.

@"Moesslacher" Thanks for the note; I'll do so.

@"Moesslacher" No, I don't have an update on this.

@"Moesslacher" Thanks for the feedback! I don't have an update on this. Please note the functionality Здравко is referring to is not publicly documented and not meant for third party use.

While a particular team admin account is needed to authorize the app when using any team scopes, the resulting connection is to the entire team, not just that particular account. You can check which account was used to authorize a particular team-linked access token though by calling /2/team/token/get_authenticated_admin…

@"FinervaStu" No, unfortunately there isn't a way to change that limit.

@"Schwankenson" This error message is referring to specifying what account on the team to operate on behalf of. For reference, when using any "team scopes", the resulting access token is connected to an entire Dropbox team, not an individual account. So, when using a team-scoped access token to access user-specific…

@"Nicolas Lavertu" Здравко is correct. And in addition to the "mode" and "autorename" parameters though, you can control the behavior using the "strict_conflict" parameter. Check out the /2/files/upload documentation for more information.

The information in the other thread you linked to is still accurate. Dropbox does not offer a way to programmatically upload larger files by link, but I'll add this thread to the feature request.

@"Adi4" As Здравко said, your destination path should include the destination file name as well, not just the parent folder. So for example, it sounds like what you actually want is something like this instead: TO_PATH = /sure/automat/copyfile