this morning i see all the users email like this :
How i can get the real email Not encoded ?
The users are under “user domain” so are “mine users”
Damn, we developed the third version of our software that interact with zoom trought user email and this morning i see that the mail are encoded, is possible to turn this encode off ? is possible get the real email ?
This afternoon i have a 75ppl meeting and i can’t change at runtime 75 emails…
PLEASE HELP !
Thanks for the post. Recently we have a bunch of enhancements that are related to those mentioned in https://blog.zoom.us/wordpress/2020/04/22/90-day-security-plan-progress-report-april-22/ so we no longer provide user email info from SDK interfaces. If you would like to get the user information, you could retrieve it from Zoom API: https://marketplace.zoom.us/docs/api-reference/zoom-api/users/user. Pardon the inconvenience caused by this.
What field i can use to map the sdk user to the correspondend api user ?
The sdk.user.id is not fixed but is like the participantid. seems i don’t have any field to map sdk.user to api.user, what is the best practise to find the correspondent api user ?
So also in the future the SDK can’t retrive the real email ?
The only solution is to integrate another level and use the API call to get those info ? Or in the future trought sdk i can retrive user email (user that are under my zoom domain) ?.
I think that if a user is under my zoom account i have all the priviledge to read the real info by sdk, if an user is not under my users account is correct to keep this info unavailable or encripted.
What you think ?
Seems like you should be able to get webhook working and map user id’s from SDK to those reported by webhook (which would have more information than desktop SDK, including email and user identity)
hoping that the webhook user email don’t get “cripted” as well in the next future…
I’m curious to see what “best practice” the staff would suggest because i don’t know if this “criptic” problem affect only sdk or also webhook.
Also, look into new SDK version - they removed GetEmail() so it’s not coming back.
OMFG! You are rigth : https://github.com/zoom/zoom-sdk-electron/commit/bde677df93a8d8d6dff65575e15f939df27ef568
if the encripted email disappear we get lot’s of problem ! I hope the staff can answer asap !
In order to user that API, one would need to have user ID from meeting. And that is not available from SDK. Would it be an option for SDK to expose unique ID instead of email?
Thanks for helping out.
Yes, that makes sense. Let me forward this to the engineering team and investigate the possibility of supporting this. Will keep you posted.
Thanks for the reply. Due to changes related to those mentioned in the 90-days security plan, this interface is unfortunate being affected. Let me work with the engineering team on your concerns and suggestions and get back to you shortly.
Hi @carson.zoom, Is there any update on this request? This would really help minimize webhook dependency
Thanks for the follow-up. Unfortunately I do not have any update regarding this at the moment. I will try to push and escalate this.
@carson.zoom - is there any workitem that I can reference in future?
Actually I found a solution that could be helpful if you are looking for the UUID of the participants. If you get the UserID from the SDK, you could make an API call to the https://marketplace.zoom.us/docs/api-reference/zoom-api/dashboards/dashboardmeetingparticipants interface and get a list of the participants’ info in the response. You could map the userID with the one provided by the SDK and get the UUID of the participant.
Hope this helps. Thanks!
We looked into this API, but I think we will hit API call rate super easy, hence webhook that we have right now is a lot better approach.
Having this information directly exposed on SDK level (IUserInfo::GetZoomID or something like that) is of much more value, and simplifies workflows, as well removes limitation on API call rate (this API is 10 requests per second and 30k requests per day).
Thanks in advance,
Thanks for the reply. I totally understand your concern. I have forwarded the feedback to the engineering team and they will investigate the possibility of supporting this.