Greg-DB Dropbox Community Moderator

Ok, the /authorize page should be behaving properly now, and returning useful error messages. For example, in this case, you should get: "More details for developers Invalid redirect_uri: "x-agent://dropbox_callback": When response_type=code, redirect_uri must start with "https://", unless it's a localhost URI."

Thanks for the report. We're looking into it.

For client-side apps like this, you should generally use the OAuth 2 "token" flow. You can find more information in the documentation for /oauth2/authorize: https://www.dropbox.com/developers/documentation/http/documentation For the redirect URI, you can either use a local address that your app will listen on, or if you're…

Thanks for the additional information. Based on those version numbers, you are indeed using the Sync SDK in both cases. I'm afraid Dropbox can't offer any further support or bug fix releases for it, per the timeline in the blog post. The change log is here though, in case the information is useful:…

Hi Francis, to clarify, what version of the SDK do you have, and what do you mean specifically when you say it "doesn't even get past the first Dropbox call" on the latest one? Based on your code snippet, it sounds like you're using the deprecated Sync SDK, which is no longer supported:…

Hi Sam, this seems to work for me: $ curl -X POST https://api.dropboxapi.com/2/sharing/list_shared_links \ > --header "Authorization: Bearer ACCESS_TOKEN_REDACTED" \ > --header "Content-Type: application/json" \ > --data "{}" { "links": [ {redacted for brevity} ], "has_more": true, "cursor": "eyJwcm9nIjogIjE0N{redacted for…

This should be fixed now in version 2.2.0. Thanks for the report!

While in development mode, Dropbox Business API apps can only be linked to a single team, as noted here: https://www.dropbox.com/developers/documentation/http/teams#production The error you're getting indicates that the app has already been linked to a team, and so can't be linked to another one.

Unfortunately, it's not currently possible to limit this (the length depends on the amount of information it needs to encode, which will vary by account). I'll send this along as feedback though.

[Cross-linking for reference: https://stackoverflow.com/questions/34415945/how-to-get-actual-versionrevision-number-of-file-containing-multiple-versions ]

The 500 for invalid IDs should be fixed now.

No update on the 500 error issue. I'll follow up here when this is resolved. The other issue, with the slightly changed file ID, behaves this way because of how these IDs are encoded. That is, a small portion of the ID (at the end) is irrelevant, so changing it doesn't affect the operation.

Thanks for the report! We're looking into these issues.

Hi Aldo, file IDs aren't really exposed to users anywhere. They're intended as an aid for developers in the implementation of apps.

Changing the contents of a file doesn't change the file ID, but does changes change the rev. That is, a file ID identifies a file, even across revisions, but the rev identifies a specific revision of a file. Likewise, if you delete and restore a file, or move a file, the ID won't change, but the rev will. If you make a…

The API v2 Java SDK downloadBuilder doesn't currently support file IDs, so you'll have to a path. I'll be sure to pass this along as a request though.

This sounds like it should be possible. Specifically: - There isn't a special kind of account for this, but a normal account should work. You can register an account here: https://www.dropbox.com/register - Yes, you can use the new API v2 shared folder endpoints to share folders and invite users:…

Richard's correct, the user needs to be involved at least once to authorize the app to access their account. There's an OAuth guide that outlines this here: https://www.dropbox.com/developers/reference/oauth-guide The only exception is if you only intend to have your app connect to your own, single account. That is…

Thanks! That also works for me, so it is likely an account-specific issue. We'll follow up here once we have an update for you.

Thanks! That's helpful. We'll look into that error. For reference, yes, both of these versions work for me: curl -X POST https://api.dropboxapi.com/2/sharing/list_shared_links \ --header "Authorization: Bearer <ACCESS_TOKEN>" curl -X POST https://api.dropboxapi.com/2/sharing/list_shared_links \ --header "Authorization:…

Thanks for the report! I can reproduce the unexpected error when supplying an empty path, which we'll look into, but I can't reproduce the 500 when not supplying a path. Can you share your code and output? The response headers would be useful in particular. Thanks in advance! 

You need to URI encode the path in the URL. For example, to download a portion of a file at "/tést.txt" using curl: curl "https://content.dropboxapi.com/1/files/auto/t%C3%A9st.txt" \ -H "Authorization: Bearer <ACCESS_TOKEN>" \ -H "Range:bytes=0-3"

This is still planned, but I don't have a timeline to share right now unfortunately. As a workaround, you can use /files (GET) on API v1 with Range Retrieval Requests, with the same OAuth 2 auth.

Thanks for the feedback, Norbert! I'm sending it along.

API v2 doesn't currently support Range Retrieval Requests, but we are planning on adding it in the future.

No update on this right now. Apologies I don't have better news!

Hi David, I don't have an update on this unfortunately. Also, we can't provide any absolute guarantee of an app's compliance based on this hypothetical description, so you should be sure to review all the guidelines and terms before developing an app: https://www.dropbox.com/developers/reference/tos…

Thanks! I can't make any promises one way or another, but I'm sending this along to the team as a feature request.

Michael, it sounds like you're seeing an error when trying to authorize your app on an account? This thread was about an error when using the /files/move endpoint in particular. Please open a new thread or open an API ticket with the details of the issue you're seeing so we can look into it.

Apologies for not followup up here! Yes, this should be resolved now.