We’re Still Here to Help (Even Over the Holidays!) - find out more here.
/oauth2/authorize (code flow) redirects to http://www.dropbox.com/home instead of redirect_uri
This OAuth2 problem appeared recently in our app (published a year ago). It closely resembles another user's forum post from 4 years ago: OAuth2 redirects to Dropbox.com instead of my redirect URI | The Dropbox Community We use /oauth2/authorize (code flow) with redirect_uri to a localhost port. The auth flow still works great in these "routine" cases when Dropbox's authorization webpage appears: User was not previously signed in to Dropbox, so signs in, then clicks Allow or Cancel. User was previously signed in to Dropbox, so clicks Allow or Cancel. Our problem is that it no longer works in this one case: User was previously signed in to Dropbox, but signs out, then signs in again (as the same or different user) in the same window. Instead of the Allow/Cancel prompt, the user is redirected to www.dropbox.com/home. (It's as if the sign-out causes the server to forget that it's still running an auth flow for our client.) I have put breakpoints in our localhost port listener, and can verify that no error is returned; it's left waiting for an error or auth code. I mention this because that was the cause of the earlier forum user's problem (a booboo in their listener). In case you're able to inspect server logs, our app's Dropbox key is enrtqx0um3pxntl. Thanks!
How to Programmatically Get a List of All Registered Apps and Their Permissions?
Hi — in the Dropbox web UI I can see registered apps ( permissions / scopes they have). I can’t find an API endpoint to fetch that same list. Is there a documented API (or other programmatic method) to retrieve all registered apps and the scopes/permissions they hold? I’ve checked the standard Dropbox API docs but didn’t spot this. Any pointers, sample endpoints, or workaround (e.g., admin/team endpoints) would be helpful. Thanks!
Scoped access within shared environment
Hey Dropbox team, I have tried to find how to approach this but can't seem to get a clear answer. Our situation: Shared dropbox directory with 5 members. These members should have access to the outputs from some automation tools. (Github actions produces .exe which gets uploaded to dropbox for all members to enyoy). Now i would like for my automation tool to only have access to the /AutomationOutputs/ directory as the rest of the drive is filled with important data which we do not want to lose. I could program my automations in a way where they never thread out of the AutomationOutputs/ directory, but I would prefer to limit the scope for the tool itself so that could never happen. What would be the suggested approach for this situation? With kind regards, Joppe
Eternal "in_progress" in "check_job_status" ?
Hi there! After creating the file transfer task, I did not get a status other than "in_progress". I checked for 10 minutes, the result is the same. https://api.dropboxapi.com/2/files/save_url Headers: Dropbox-API-Path-Root:{".tag":"root","root":"***11017011"} Content-Type:application/json Body: { "path": "/TrueCare24/Getting started.pdf", "url": "https://cdn.filestackcontent.com/4HanfOIvSVW4gHeOUbm9" } Response: { ".tag": "async_job_id", "async_job_id": "SPaPOLIucOYAAAAAAAAAAQ" } https://api.dropboxapi.com/2/files/save_url/check_job_status Headers: Dropbox-API-Path-Root:{".tag":"root","root":"***11017011"} Content-Type:application/json Body: { "async_job_id": "SPaPOLIucOYAAAAAAAAAAQ" } Response: { ".tag": "in_progress" } There are no problems with other files. I have transferred many thousands of files and everything is ok. TrueCare24 is Team Folder
May timeouts when calling get_current_account endpoint
We’ve noticed a recent surge in errors reported by some users of our app when calling the get_current_account endpoint. Specifically, the requests are timing out, which is unusual because we haven't had any issues and our code has not changed. This issue started occurring last week and seems to be affecting users mainly in Canada. Could you help us understand if there are any known issues on Dropbox’s side, or if there have been recent changes to the API that could be causing these timeouts? Thanks in advance for your assistance! Regards, EnriqueSingle API call creating duplicate file versions using Dropbox .Net Api
Hi Dropbox Support, I'm experiencing an issue with the Dropbox .NET API where a single file upload API call is creating two identical versions of the same file with the following problems: Problem details: Using Dropbox .NET API for file uploads One API request results in two file versions created 1ms apart Different attribution: One version shows "edited by user on web", the other shows "edited by user on API app" All uploads are done through API only - no web interface involvement This happens inconsistently - some files upload normally, others create duplicates API methods used: For small files: uploadArg = gcnew Dropbox::Api::Files::UploadArg(dropboxPath, Dropbox::Api::Files::WriteMode::Overwrite::Instance, false, clientModified, true, nullptr, false, nullptr); uploadTask = m_dropboxclient->Files->UploadAsync(uploadArg, fileStream); For large files: task = m_dropboxclient->Files->UploadSessionFinishAsync(cursor, commitInfo, nullptr, fileChunk);
