When a join URL is generated, we receive a participant ID. This participant ID is stored in our DB to match a user in our system to the join URL which we generated for them. This way, after a meeting/webinar is finished, we expect to be able to fetch reports and map this participant ID to the user in our DB and show nice reports. Sounds simple and logical.
The problem is, this workflow seems to work only for webinars (although I am not entirely sure). For meetings (v2/report/meetings/{meetingId}/participants) the returned data is highly unreliable. “Id” can be blank, “email” can be blank or different from what was provided etc. etc. From what I understand skimming through the forum, the returned information depends on what particular way the user was signed in. Our application cannot track user actions like that.
One of our engineers previously (a year ago) came up with a hack to pass a fake email which embeds the ID from our DB. This way we could parse the returned email and match to the data in our DB. But he found out that the email could be different in the reports if the user signed in in some particular way. So the final more-less reliable solution he found was to embed our internal user ID in the user name which is passed when generating the join URL. The problem with this approach is that a user can rename themselves and the mapping will be broken.
The question is, what is the proper, reliable way to fetch participation duration reports for webinars/meetings when joining through a generated URL, no matter in which way the user logged in/joined?