API Endpoints Used
POST to /users/{userId}/meetings
POST to /meetings/{meetingId}/registrants
PATCH to /meetings/{meetingId}
Description
This is what we’re doing:
We create a meeting with a POST to /users/{userId}/meetings. The setting “registration_type” is 1, which is “Attendees register once and can attend any meeting occurrence.”
We set the setting “approval_type” of the meeting to “0” (Automatically approve registration), so we can register people for the meeting.
We go through our list of people and register them all, including setting the name, using a POST to /meetings/{meetingId}/registrants
We now set the setting “approval_type” of the meeting to “2” (No registration required). This is so that people who join with the “Share a join URL” don’t have to register, but can just simply click a link.
We want to do two things in the same meeting:
We want to be able to give each of our people his own URL to the meeting, so his name will be correct when he joins. (“approval_type” must be 0 to do this.)
We also want to use the “Share a join URL” to give to other people, who won’t have to register with a Zoom account. They should just type in their names and get in. (“approval_type” must be 2 to do this.)
Error?
This works, except that when correctly registered people click their personalized join URL, they sometimes show up with the wrong name. They should show up in the meeting with the name we gave them in step 3. But sometimes their name is “iPhone”. It looks like this might be a bug with your iOS app.
How To Reproduce Steps to reproduce the behaviour:
Create a meeting where “registration_type” is 1 and “approval_type” is “0”.
Register a registrant with the name “Bob”, and remember his join URL.
Set the meeting’s “approval_type” to “2”.
Start the meeting.
Bob should now click his personalized link on an iPhone.
When Bob shows up in the meeting, as viewed by someone else, his name should be “Bob”, but sometimes it’s “iPhone”
Troubleshoot what, exactly? If you know a way around this bug, I’m happy to hear it. Otherwise, we’re patiently waiting for it to get fixed by your developers. But I haven’t heard any feedback at all from Zoom. I would love to hear even a, “Yes, I understand the problem, and it’s on our list to fix.” Even that would make me happy at this point.
Hi Tim,
I tried replicating the issue you are seeing using the steps you provided in the initial thread and I am not able to troubleshoot this on my end.
After changing the approval type to 0, I can still use the join link and access the meeting with the name the participant got registered with
Thanks for looking into this, Elisa. It just occurred to me that I could test this with the web UI instead of the API. I’ll try that.
But I think you mean “2”, not “0”. You said, “After changing the approval type to 0, I can still use the join link…” But this issue was changing it to 2, not 0.
Yes. This is all with the API. We sometimes have up to 30 meetings in a day, and we register each person as a registrant and give each person their own URL, so when they click the URL, they get their own names displayed. This is all automated. But we also want the ability to share a join link from the Zoom app. I believe “registration_type” must be 0 in order to register a registrant, and it must be 2 in order to share a meeting link. So our code does this dance of first setting it to 0, then registering everyone, then setting it to 2 so the leader can share a link. But when we do this dance, the iOS app stops showing the registrants name when a registrant clicks their custom link.
Hi @tim2
I tried reproducing this and I can not. I followed all the API calls you shared.
I can send you a link to my scheduler if you want to book some time with me and show me live because I do not see that behavior
I would love if the problem was on my end. That way I could fix it.
I would be interested in looking at your script or code, so I could compare it to what I’m doing.
Well, we finally looked at our code in depth, and found that we are doing something non-standard. So maybe it’s not a bug, because what we’re doing is not really documented. So we fixed it a different way. But thanks for looking into it, Elisa.