Can you confirm you're using an API app registered with the "app folder" access type? There is a bug that results in this error when using this method with an access token for an app folder app. That's still open with engineering, but I don't have a timeline on a fix.
Yep, that's exactly correct, thanks for the fill-in.
So with global Dropbox access scope it doesn't happen? That's a much higher trust barrier to get over for users, unfortunately.
And just to check: I don't think there's an auth flow for users to make that decision (regarding access scope) for themselves, right? Can an app request global scope, be rebuffed and given only AppFolder scope, and then have to figure out for itself what it should do (e.g. regarding paths)? That way if a user only allowed AppFolder scope, I could just notify them that sharing won't work for the time being.
But as it stands currently, [global scope] vs [app folder scope] is solely set from the DevConsole, is that correct?
Anyway, regarding the root issue of broken shared links in AppFolders, as a temporary workaround it would be pretty sweet if someone at Dropbox could turn on the Access-Control-Allow-Origin header for publicly shared links, so a regular JS fetch() call could suffice. Or maybe set up a temporary CORS proxy, so I don't have to pay to run one myself? Pwetty pweeze? 😛
Yes, this bug only affects apps with the "app folder" type, not the "full Dropbox" type.
And that's correct, the "app folder" versus "full Dropbox" type is selected when first registering the API app. There isn't a way to dynamically set or fall back on that, e.g., during the authorization flow. You could register one of each however and switch between them as needed though.
Anyway, I can't make any promises on a workaround, but I'll pass it along.