Just looking at creating a meeting via the api and noticed the documentation only has registrants_email_notification in the request schema and example.
However the response (and also when you get a specific meeting) has both registrants_email_notification and registrants_confirmation_email listed in the schema and example.
So first of all these are very similarly named options and descriptions. Do they do different things? registrants_confirmation_email suggests that the registrant will get a confirmation email after they have been approved if true.
registrants_confirmation_email
Send confirmation email to registrants
registrants_email_notification
registrants email notification
So what does the registrants_email_notification do?
And why isn’t registrants_confirmation_email in the request schema settings?
So I’ve noticed that they don’t appear to be connected as an alias, and it doesn’t seem possible to actually pass a value for registrants_confirmation_email
It just sets to a default true
How are you meant to stop it sending confirmation emails by default?
Thanks @tommy, yeah it seems to be impossible to set registrants_confirmation_email when the zoom meeting is created via the API. So the documentation is technically correct atm, but it should be added to docs and made possible to send a false value.
I’ve current got my code calling a PATCH after its created to set it to false which works but feels a bit hacky when it should just need one call.
I’m a bit amazed that nobody has spotted this, unless its not common to send your own emails. If there was a way to brand via the API then I might use that, but seems only possible in the account manually.
@tommy just noticed another undocumented quirk, registrants_email_notification needs to be true if you want registrants_confirmation_email to be true.
If its registrants_email_notification is false you still won’t get the confirmation email even if registrants_confirmation_email is true
So you can’t disable the registrant status/reminder emails without affecting the confirmation email.
I would have thought these should be independent actions, or at least documented that setting the registrants_email_notification to false takes precedence and stops confirmation emails.