How to match UserInfo provide from sdk with UserInfo from server?

Hi there, as I describe in this post about half year ago:

in session 5:

5.For this case I check with our server and found out that this is the userId indeed. We have migrate the sdk to our app and there’s large part handle by server so I think it cannot be reproduce on demo app. But I can explain the as the flowing:
In our app, we start a meeting with by the following code:
zoomSdk.meetingService.startMeetingWithParams(context,StartMeetingParamsWithoutLogin().apply {
userId = serverReturnUserId
zoomToken = serverReturnZoomToken
zoomAccessToken = serverReturnZoomAccessToken
userType = MeetingService.USER_TYPE_API_USER
displayName = myDisplayName
The first three params are retrieve by our server.
And when sdk callback the status is inMeeting, we call Log.d(TAG, “my email:” + zoomSdk.inMeetingService.myUserInfo?.email) and it will return some “random string” -> my email:7iOdbzqbT7Wm9F5-SLYHPA(we later found that it’s the userId), for these account the email should be []( Is is expected? Although it’s kinda weird to put it in email field but it’s ok now, we can ask the server to parse userId to email. So this can be consider solved. Thanks anyway.

So last year, the sdk return the “random string” from email field we later found it’s userId, so we match it with the userId provided by our server which was fetched from zoom API.(BTW the userId is meeting base and may change between different meeting so we cannot use it as the identity of a user)

But recently we found that it return the actual email like I described above!
We didn’t upgrade the sdk so I expected zoom server api change recently.
And our product used android, IOS, web sdk, all have this issue.
As the result of that, some of our product feature is not function well.

Here is my questions:

1.Did the zoom server make the change about this field? If yes, when did the zoom deploy the change?

2.Can we continue to use this field as the identity to match the userInfo from sdk and from server(fetch from zoom api). That is if the email from the UserInfo provided by zoom sdk(android/IOS/Web) equal to the email from the userInfo provided by zoom API, then we condiser it’s the same user.
If we cannot, can you tell us the alternative ways? This is quite important.

3.If the answer above is yes, then can we expect this field surely will only be email in the future, and will never change back to userId?

That’s my question, wish to get the reply soon.

BTW, it’s just my little suggestion. For better backward capability, can I expect zoom won’t change the content of the exsiting field? The client side cannot garentee to upgrade in time, thank you so much.

1 Like

Hi John_Doe,

Thanks for the post. Regarding your questions:

  1. I do not aware the update on this thus I am confirming with other teams on this. The intention of the getEmail field is to return the email address of the user as described in If it was returning random strings, them it was unexpected behavior.
  2. You could use the email address as the userID when you contacting with Zoom Rest API as mentioned here

In both of these cases, provide the actual userId or email address of the user whose details you would like to view as the value of the userId path parameter

The userID returns in UserInfo().getUserId() is an user ID only valid in the current meeting, it will change in different meetings. The ID returned by rest API such as is the UUID of the user, it stays the same all the time.

  1. Yes, as mentioned above, the intention of the UserInfo().getEmail() is to return the email address. It should stay with this functionality now and in the future.

Pardon the inconvenience caused by this. Normally we do not change the contents return by each interfaces, if it returns something that is out of the intention of the method, please let us know and we will fix it asap.

Hope this helps. Thanks!

Thanks Carson_Chen,

We’ll use email as the userId and the feature is back to normal now.
It shoule be fine as it’s confirmed by offcial devforum, what a relief.
We’ll report if things not going as expected in the future.

Thanks again!

Hi John_Doe,

Thanks for the reply and pardon again for the inconvenience caused by this. Happy Zooming!