Dropbox Account Id vs UID

[Jiho P.]

Hello, I'm using Swifty dropbox and wanted to know the difference between accountId I get from getAccountId() call vs. the userId set in my shared client.

Thanks in advance!

[Greg-DB]

Arusnundar, you can call /2/users/get_current_account for any given account using the account's access token and store the new account_id value from there.

[Arusnundar S.]

Gregory,

I have already stored the user id (UID integer) in the Database. But I didn't get UID instead of DBID. You told correct, i will stored the account_id. Even I need the UID to get for old user account info. 

My Questions is,

1. Is there any function to get UID in V2 version not V1?
2. How to migrate the UID to DBID?

Please give a solution.

[Greg-DB]

1. No, API v2 doesn't return the v1 user ID.

2. For each user you have, with a known user ID and access token, use that user's access token to call /2/users/get_current_account and store the resulting account ID as being for that user.

[Steve L.]

Poking this thread back into life,  is there a way in V2 to get the V1 userId?  

[Greg-DB]

No, API v2 does not offer a way to get the v1 user ID.

[Steve L.]

I have no problems changing to use the accountID going forward, but it would be very helpful if there were a way to get the V1 userID (read-only) for those who have thousands of existing installs that use the Dropbox V1 userID as a primary key.   As things stand there's no way to associate existing users with their data.

[AEmery]

Another problem I'm running into with the removal of the userID is that the URL to a file revision history is using this userID. These URLs are in the following format: https://www.dropbox.com/history/[PATH_TO_FILE]?_subject_uid=111111111. Is there another way to generate them now that API v2 no longer returns the userID?

[Greg-DB]

Thanks for the feedback everyone!

No, unfortunately there isn't a way to get these IDs or generate these links, but I'll be sure to pass this along as a feature request.

[Tony001]

We are finishing up our API migration, and hit a bit of a snag here. The solution for mapping old account IDs (uid) to new account IDs (account_id) seems to be a proactive call to the V2 API with an existing token to retrieving account_id. Is this correct?

Does this mean that we need to get every user (we have tens of thousands) to use our app in some way so we can piggyback a call to get account_id before the V1 api is shut off? If a user takes a hiatus from our app and then tries to use it after the V1 API shutoff, there would be no way to associate the IDs at that point, correct?

I don't suppose there is a way for you folks to add uid to the get_current_account return?

Barring that, is there a better way to do this to prevent some users being caught on the outside of the transition?

Will existing tokens remain valid after the V1 shutoff?

[Greg-DB]

"The solution for mapping old account IDs (uid) to new account IDs (account_id) seems to be a proactive call to the V2 API with an existing token to retrieving account_id. Is this correct?"

That's correct, you should call /2/users/get_current_account with the existing access token to get the account_id.

"Does this mean that we need to get every user (we have tens of thousands) to use our app in some way so we can piggyback a call to get account_id before the V1 api is shut off? If a user takes a hiatus from our app and then tries to use it after the V1 API shutoff, there would be no way to associate the IDs at that point, correct?"

You don't technically need to do this before API v1 is retired. Also, you don't really need to wait for users to be active to make this API call. As long as you have the access token, e.g., for a server-side app, you can just make the API call whenever you'd like. (For a client-side app, yes, you'd have to have them run the app, since you presumably don't have the access token anywhere except on the client.)

"I don't suppose there is a way for you folks to add uid to the get_current_account return?"

I've sent this along as a feature request, but I don't have any news on that.

"Barring that, is there a better way to do this to prevent some users being caught on the outside of the transition?"

I do recommend just going through all of the existing access tokens to get and record the account_id.

"Will existing tokens remain valid after the V1 shutoff?"

Access tokens aren't being deactivated. In fact, if you have OAuth 2 access tokens, you can use those directly on API v2. (One exception there is if your app happens to use the "file type" permission, which isn't supported by API v2.) If you have OAuth 1 access tokens, you can migrate them to OAuth 2 using API v2's /2/auth/token/from_oauth1.