"Approve Registrant" does not return "join_url"

Description

I’d like to approve registered participants manually through the API.

For this I’m using the Update Meeting Registrant Status API - and setting the action to “approve”.

But once I make this call, I don’t get the “join_url” returned [with the registrant’s unique code]

And without the “join_url” - I’m not able to provide the participant the URL to join the meeting.

NOTE: I always create the meeting with “approval_type” set to “1” and “registration_type” set to “2” - when calling the Create a meeting API

The workaround we’ve tried

We’ve tried a workaround for this - which is to automatically approve the registrant (if they’re already authorized by our system). We do this by setting the “approval_type” to “0” [in the “Create a Meeting” API call]

But we have another issue when we try this method: participants can get access to the meeting URL - can bypass our system completely. To solve this problem, we’re using the “Meeting Registration Created” webhook - and then denying anyone coming in directly through the meeting URL.

But…we have an issue with this as well. The above webhook doesn’t get fired when the meeting URL is accessed from the Zoom mobile apps.

Summary

In summary, we’re stuck.

I think it would be ideal if you could return the “join_url” when we approve registrants through the API.

PS: Our app is an OAuth Account Level app.

1 Like

We’ve already reported the “Meeting Registration Created” Webhook-not-getting-fired issue.

@tommy Can you please take a look at this issue? Thank you!

Hey @vaidy,

Are you able to get the join_url from the List Meeting Registrants endpoint?

Thanks,
Tommy

Thanks for your response, Tommy.

To answer your question, yes, we are getting the join_url in list_registrants.

However that is a workaround that we’re hesitant to use - because we’d need to call it every time a pre-authenticated student tries to join their Zoom class.

As mentioned earlier, our goal is to automatically allow authenticated students on our system into their respective Zoom meetings - whenever they try to join a zoom class.

Since we don’t know which students will want to join which class beforehand, we only add them as meeting_registrants at the last responsible moment (which is whenever they indicate that they want to join a class).

So, we’d need to call list_registrants soon after every student is registered - and then search for our new student from that list. This is something that we’d like to avoid, since it’s not very efficient.

Is there any chance that you could provide the join_url in the approve_registrant response?

Hey @vaidy,

Gotcha, I have asked our engineers to provide the join_url in the approve registrants response. I will keep you updated (ZOOM-160331).

Thanks,
Tommy

Thanks Tommy!

Looking forward to seeing this added.

Hey @vaidy,

After speaking with our engineers, they do not plan on returning the join_url after approving a registrant.

That being said, an email is sent to the registrant with the join_url after they are approved.

Or if you want to handle the join_url logic programmatically you will have to use the List Meeting Registrants endpoint.

Thanks,
Tommy

Oh! That’s a bummer.

Can I ask why they choose not to send it in the Approve response? I’m sure they have a good reason, will help me understand your API design better.

Hi, in Webinars there is a way to get the information of a specific registrant (Get a Webinar Registrant), why do not include this feature for Mettings?

I’m agreed with thread starter.

Zoom should have return join_url when execute [ Update Meeting Registrant Status ] to approve registrant status.
Because some developer need to save join_url in their database to use for send an url via SMS or via their private email server.

Not efficiency to run [List Meeting Registrants] every time when need to fetch join_url.

Oh! and I have a question.

What if I set to Automatically Approve when register so I can get join_url from [Add Meeting Registrant] right away then I run [Update Meeting Registrant Status] to change from ‘Approved’ to ‘Pending’ will this work ? If it’s work then I don’t have to run [List Meeting Registrants] anymore. ps. I’m not trying yet.

Thanks !

OK, I know how to fix the problem. Just use webhook Meeting Registration Created after add registrant and boom done. I’ve got join_url :stuck_out_tongue:

1 Like

@tommy

Since this is a no-go, can you guys fix the registrant-webhook-not-firing-from-android issue?

If that bug is fixed, we can move forward with a reasonable solution. Otherwise, we’re stuck :expressionless:

Hey @pingchp, @herogp,

Yep, that is the best way! Use the Registrant Created / Approved webhooks to get single registrant instance.

I will ask engineering to add the join_url to the Registrant Approved Webhook. (ZOOM-162957)

Thanks,
Tommy

Hey @vaidy,

We will work on fixing the android issue asap.

Thanks,
Tommy

Thanks @tommy

We haven’t tested whether the issue happens in iOS. Can you take care of that as well? Thanks.

Hey @vaidy,

Yes, we will look into it, please stay updated on this thread:

Thanks,
Tommy

I have encountered precisely the same issue as @vaidy today in my own integration work. To date, I have not needed to implement any webhook functionality and having to do so for the sake of this issue, which IMO boils down to an API deficiency, is frustrating and disappointing.

Is it possible to get any more clarity on why the engineering team cannot update the Update Meeting Registrant Status API to return the join_url when approving a registrant? (My best guess would be as it requires changing the HTTP status code of the response from 204 to 200, which might break some integrations.)

Failing that, I like @herogp’s suggestion to replicate the Webinar ‘Get Meeting Registrant’ API over to ordinary meetings (which to be honest, I was mildly surprised was not already present).

The proposed workaround of using the List Meeting Registrants API is the avenue I have had to proceed down before finding this discussion thread, but as already pointed out, it is a poor and heavy-handed workaround.