Zoom meeting manual approval denial webhooks

[ajay.surti (Ajay)]

Hi @will.zoom , @tommy

Zoom webhooks send different events (meeting.registration_cancelled) instead of (meeting.registration_denied) it gets denial from a host on the manual approval process.

at the moment I am updating each meeting to set
‘registrants_confirmation_email’ => false,
‘registrants_email_notification’ => false
to make sure that I would not receive a zoom branded email and I am using webhooks to send a custom email to the user.

here are 3 important bits I would like to point out.
Despite the meeting has been updated to the above-mentioned flag it’s sending a zoom branded email

1. when a user gets denial for zoom meeting (zoom meeting manual approval process)
2. I am sure when the user gets denial the event meeting.registration_denied should trigger instead
   meeting.registration_cancelled
3. when meeting details has been updated its triggers a zoom email.

As I am getting duplication of email when a meeting gets denial as well as when the zoom meeting details have been changed/zoom meeting updated. (one from zoom and one from webhook driven custom email)

Can you please advise on the current solution to overcome the above situation at the moment and confirm the above if that’s not the case?

Thanks
Ajay.

[MaxM]

Hey @ajay.surti,

Thank you for reaching out to the Zoom Developer Forum.

I am sure when the user gets denial the event meeting.registration_denied should trigger instead
meeting.registration_cancelled

We don’t currently have a meeting.registration_denied webhook. If you would like this feature to be considered for a future release, I recommend posting in the Feature Requests category.

when meeting details has been updated its triggers a zoom email.

How are you updating the meeting? Through the API or through the Client / Web Interface?

Instead of using webhooks to set branding on your emails, you may be interested in using our Custom Branding tools to configure cust email templates.

I hope that helps!

Thanks,
Max

[ajay.surti (Ajay)]

Hi @MaxM

Thanks for you quick response

@MaxM

We don’t currently have a meeting.registration_denied webhook. If you would like this feature to be considered for a future release, I recommend posting in the Feature Requests category.

Just on your comment please find the attached event from my zoom app, which I have captured, and it has the denial event and the concern I have raised here is when the user gets denial on webhook response I am getting “meeting.registration_cancelled” event. so if it’s not implemented from your end I would request for the feature should be implemented.

From the documents, it says if I would set the “registrants_email_notification” flag to false for a specific meeting then it would not send an email to registrants. but that is not the case at the moment as I am still getting an email as registrants from the zoom portal.

On the second query, I am updating the meeting from API as well as from the zoom portal, I have found the workaround for it, which is the tick box when we update the meeting I am making sure it’s not ticketed and it is not going to send any email from zoom portal.

I have attached the screenshot for my webhooks event subscription along with this message, please have a look.

The reason I am not using branding email as the option for localisation (sending an email in spanish/french) is not available at the moment (which is I have been told buy your dev team and thats the reason I am using webhooks, so I can send an email in multiple languages based on the registrants preference)

Thanks
Ajay.

[MaxM]

Hey @ajay.surti,

Thank you for providing additional information, I appreciate all the detail. I looked into this further and it looks like we do have a meeting.registration_denied webhook but it’s not documented.

@shrijana.g Can we add documentation for the meeting.registration_denied webhook?

When testing, I saw that the meeting.registration_denied event fired without an issue when I made the following request to the Update Meeting Registrant Status API:

Method: PUT
Endpoint: https://api.zoom.us/v2/meetings/:meetingId/registrants/status
Body:

{
  "action": "deny",
  "registrants": [
    {
      "email": "registrant@fake.email"
    }
  ]
}

After that, I saw the meeting.registrant_denied webhook was fired. I saw this same behavior when enabling manual approval and denying the registrant from the web interface.

From the documents, it says if I would set the “registrants_email_notification” flag to false for a specific meeting then it would not send an email to registrants. but that is not the case at the moment as I am still getting an email as registrants from the zoom portal.

I was able to reproduce this issue and I’ve since reached out to our engineering team to see if this can be fixed. (ZOOM-244951) I’ll be sure to keep you updated.

Thanks,
Max

[ajay.surti (Ajay)]

Hey @MaxM

Thanks for your quick response, I would really appreciate it.

Can you please cross check on below senario:

@MaxM

Method: PUT
Endpoint: https://api.zoom.us/v2/meetings/:meetingId/registrants/status
Body:

{
  "action": "deny",
  "registrants": [
    {
      "email": "registrant@fake.email"
    }
  ]
}

After that, I saw the meeting.registrant_denied webhook was fired. I saw this same behavior when enabling manual approval and denying the registrant from the web interface.

After denied the user, can you cross check the response body from “denial” webhook as I am getting
“event:meeting.registration_cancelled” in webhook response/body instead of “event:meeting.registration_denied”

I am glad to know that you guys are quick to work on the bugs that have been pointed out, and I can see that from the response I get from your team when I raise any query.

Please update me as soon as it’s on your prod env and I will test it from my end.

Thanks
Ajay.

[MaxM]

Hey @ajay.surti

Thank you for the update.

@ajay.surti

After denied the user, can you cross check the response body from “denial” webhook as I am getting
“event:meeting.registration_cancelled” in webhook response/body instead of “event:meeting.registration_denied”

When I was testing, I didn’t see this behavior but there might be an edge case that I’m missing. Are you denying users through the Web Interface or the API when this happens? Are there any meeting settings that this seems to happen with or any other details that might help me to reproduce the issue?

@ajay.surti

I am glad to know that you guys are quick to work on the bugs that have been pointed out, and I can see that from the response I get from your team when I raise any query.

We appreciate the appreciation! I’ll be sure to keep you posted on the progress of the bug.

Thanks,
Max

[MaxM]

Hey @ajay.surti,

Thank you for your patience. Our engineering team got back to me and indicated that this issue has since been resolved. Please test this and let me know if you are still encountering this issue.

Thanks,
Max