Appending Custom Parameter to Zoom Join_URL? continued II

I’m not a big fan of auto-closing topics. Instead of just adding a new item to the conversation, I have open a new topic. Can you imagine how StackOverflow would look like when questions were auto-closed after 30 days? Exactly.

Following up on Appending Custom Parameter to Zoom Join_URL? continued], I can confirm that what was suggested by the friendly Zoom-staff does pretty much what I was after. For anyone interested, here’s the summary of how it works/does not work:

  1. You can pre-register attendees through the API with their first and last name. An e-mail address is mandatory. Because we don’t want to share this with Zoom (sharing less information is always better), we just make up e-mail addresses with the attendee ID in our own database on our own domain and hope that Zoom will not ever contact them. They will bounce. We will try to install a wildcard filter on our mailserver and send them to /dev/null

  2. Every attendee/registrant gets its own personalized Zoom join URL. This is good. There is a downside though: these join links are hideously long/ugly. We can work around that with an intermediate landing-page on our own website.

  3. The cool thing is that through pre-registration the attendee names are as you expect them to, and it seems they cannot be changed within the meeting. That is what we wanted afterall. The e-mail addresses I mention above will be used to identify the attendees in our database.

  4. Another nice thing is that the super annoying CAPTCHA will not be shown when the join link is used and someone does not have a Zoom account/is logged into the website or client. Weird as it may sound: when someone is logged in the Zoom client, the profile picture is being used from that account, but the name is from the registration. Probably not what Zoom intended.

  5. Another downside of this process is that it’s not supported for people joining with a web browser. They just get to see a message that for registration, the Zoom client is required.

  6. If you don’t want other people to register for this meeting, set the meeting’s registration options to “Manually Approve”. The API will unfortunately not return the join URL then, but that’s easy to fix: there’s a parameter to pass “auto_approve”. The docs don’t show this in the example JSON, so I guess it was added later. I understand why. You want this.

In general, some is good, some is bad. We have to evaluate if the pros outweigh the cons.

@tommy It seems that the “Agreement/disclaimer” that we put up on all our meetings, will not show up for registrants. Is this a bug, or expected behavior?

1 Like

Hey @BoringUsername,

Thank you for sharing what worked for you! I’m glad that you found a way to use custom parameters with the join_url.

It seems that the “Agreement/disclaimer” that we put up on all our meetings, will not show up for registrants. Is this a bug, or expected behavior?

I tested this on my end and saw that when I used a Custom Meeting Disclaimer it was displayed to a registrant when they joined the meeting. You may want to enable it for internal and external participants to make sure that you aren’t missing any edge cases:

Let me know if that helps.

Thanks,
Max

@MaxM Thanks for the info. I checked the disclaimer-setting, and it seems that the account I was testing with (our “owner”-account), did not have the option set to show the disclaimer (all our other accounts are in the same group, which do have the disclaimer), so it had nothing to do with registration. My bad!

Hey @BoringUsername,

I’m glad to hear that you resolved your issue! Please don’t hesitate to reach out if you encounter any further issues or questions.

Thanks,
Max

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.