Description
When scheduling meetings via the API for users that have “Require a password when scheduling new meetings” enabled does not result in a password being required. We do not specify the password parameter when scheduling the meeting, but we’d expect a password to be auto generated due to the “Require a password…” user setting. Is this expected? An example meeting is 82529829258
It looks like the only difference here is that you have the setting locked while we do not. Is that still expected that a password is not required in that case?
@mattpegler when the setting is not locked, the API is interpreting that a password is not provided intentionally.
It still seems weird that a user with require_password_for_scheduling_new_meetings enabled isn’t required to set a password when scheduling new meetings. We’ll change it on our side to help our customers, but I do think this is unexpected and flawed behavior.
Maybe consider renaming that setting to something like require_password_for_scheduling_new_meetings_except_via_the_api
@mattpegler I think that would take the record for longest property name 
Joking aside, I get the weirdness around this flow. We’re evaluating how to make this cleaner, but there were reasons we chose this initially in order to not unexpectedly break some key integrations and allow account settings to be overridden when not locked.
Supporting legacy users is always cumbersome. I get it.
The weirdness with this setting continues for us. If a user has use_pmi_for_scheduled_meetings enabled, it looks like we’ll clobber the existing password when we schedule new meetings. So any meeting URLs that have been sent out with the password embedded in the URL will not be valid because it looks like the user’s personal meeting room’s password gets changed.
Hey @mattpegler,
If the user is using PMI for scheduled meetings, and they require a password, it should not change the PMI password.
Thanks,
Tommy