Greg-DB Dropbox Community Moderator

@"bellissimo" Work on this issue is still in progress. I'll follow up here once I have an update on it.

@"pradikrish" You can find the expected headers and parameters for any given API endpoint in the API documentation. For example, here is the documentation for /2/files/upload.

Thanks for the report. This is a known issue and we're currently looking into it. You can find more information in this thread.

Due to indexing delays, sometimes new changes may not immediately be returned in search results. The length of the delay is generally short, but sometimes may be longer. Since this is happening on both the API and web site, it sounds like an indexing issue with your account rather than some issue calling the API itself, so…

I'll follow up here once I have an update on that.

Thanks for following up. I'm glad to hear you got this working. The original error is expected if the authorization flow is processed in an web view. That's not officially supported so you should not so, and the current version of the SDK should not do so anyway. Anyway, the second error is a different problem and is a…

@"abiluck" Thanks for the note. This is still open with the team. I'll let you know as soon as we have an update on that.

Thanks for the report. It looks like you're using the Dropbox Java SDK. Can you let me know what version number of that SDK you have installed? Also, have you made any modifications to it? I just tried this and this error doesn't reproduce for me. Additionally, please let me know what browser and version number of that…

The /2/file_requests/update endpoint is for updating "file requests", not actual files/folders. To rename a file or folder, you should use /2/files/move_v2. When supplying the "id" of a file or folder, supply it exactly as given. That is, do not remove the "id:" prefix or otherwise modify the value. To rename a folder, you…

If "the integration says that the folder with that name doesn't exits" when it does actually exist, there may be a bug in the integration. We can't provide support for third party apps themselves, so you may need to debug that or contact the third party developer for help. If there seems to be a bug with the Dropbox API…

If an app attempts to create a folder at a path where one already exists, the Dropbox API will return this error indicating that there's already a folder at that path. There isn't a way to change that particular API behavior, but the app can decide what to do with the error (e.g., to ignore it, or some other error handling…

Could you open an API ticket with a few sample 'X-Dropbox-Request-Id' response header values for these 5xx errors? That should help us investigate. Thanks in advance!

@"patrikc" This is still the case. The Dropbox API still doesn't offer functionality for restoring entire folders.

Dropbox doesn't have any official resources for Lua in particular, but perhaps someone else on the forum has something they can share. As for the functionality itself, note that every Dropbox user API access token identifies one specific app-account pair, and allows access to that account to the extent allowed by the app's…

@"abiluck" No, unfortunately I can't make any promises right now. I'll follow up when I have any news on this from the team.

To create a shared link for any particular file or folder using the Dropbox API v2 JavaScript SDK, you can use the sharingCreateSharedLinkWithSettings method. To retrieve existing shared links, you can use the sharingListSharedLinks method.

@"bdrhoa" Thanks for the feedback!

I can only help with questions about the Dropbox API itself. For help accessing other features or configuring your account(s) please reach out to support from the relevant account(s) here.

That's correct, the Dropbox webhooks functionality does not follow redirects, but I'll pass this along as a feature request. There does not currently appear to be plans to implement support for that though.

The output you shared here appears to be from /2/files/list_folder[/continue], which only returns file/folder metadata, but not any actual file data. To access actual file data, e.g., to display it in your app, you can instead use /2/files/download, to download the original file data, or /2/files/get_thumbnail_v2, to…

No, unfortunately there isn't a way to make that work that way. Access in the Embedder depends on the single shared link you supply to the Embedder (i.e., for the parent folder, in this case). If that link doesn't have a password enabled, then the end-user will be able to access the linked folder and all of its contents…

Thanks for the note. The 'allow_download' API option hasn't been incorporated into the Java SDK yet, but it should be included the next time the Java SDK is built with the latest version of the API spec.

I see you have an open support ticket regarding this issue. I don't have anything to add to that, but support will follow up with you there as soon as there's an update to share.

Thanks for the report! This is an issue with the current version of the Dropbox app on Android 11+. We're currently working on a fix. I'll follow up here once I have an update on that.

Can you check you're updating the configuration for the correct app, that is, for the app with the app key you're using in your code for the Chooser/Saver? If you'd like us to check on this specifically for you, please share the full URL(s) that aren't working as expected. Feel free to open an API ticket if you'd prefer to…

I see, thanks. I believe in that kind of setup, the reverse proxy would actually obscure the issue we found, since it's making the request on behalf of the client, instead of the client doing it itself. (And according to a sample I saved from October 1, we were already previously sending 'X-Content-Security-Policy' anyway.)

Thanks for the report. Did you already resolve this? I just tried loading the site you shared in Safari with 'Prevent cross-site tracking' enabled and the script seemed to load successfully for me.

You can use an audience of LinkAudience.NO_ONE when creating the shared link via createSharedLinkWithSettings, so that only those with access to the file (such as granted by addFileMember) can access it.

Thanks for sharing this. Can you also share any documentation or output showing that's the issue though, for our reference? I ask because we're still looking into this, but we believe we've found a behavior on our side that, in some cases, would affect the content type that the client is using. I'll follow up with any…

Thanks for taking the time to share your experience and write up and post this guide. I hope it can be of use to others here.