API Endpoint(s) and/or Zoom API Event(s) POST /users/{userId}/meetings
Description
As part of development of an application I need to check validity of a Meeting/Webinar passcode before creating the Meeting/Webinar.
The flag options for Meetings / Webinars passcode validation are present in the Zoom GUI in the Zoom Account settings, and those same configs are reflected in the output of GET /accounts/{accountId}/settings
While the rules mentioned in the API documentation and GUI are mostly self-explanatory, the rule related to “consecutive characters”, is not completely clear:
“qwert” is mentioned as example of consecutive character: does this imply that all subsequent sequences of keys on a QWERTY keyboard (from left to right) are classified as “consecutive characters”? If yes, is this rule checked against other keyboard formats (Coleman, Dvorak)?
Additional questions related to this topic:
I was unable to find a more formally defined list of constraint that a Webinar / Meeting password must abide. Is this officially documented?
Does Zoom exposes or is planning to expose an utility API endpoint that only performs the validity of a given passcode against the current configuration of an User/Account?
Hi @andrea.bonanno
Thanks for reaching out to the Zoom Developer Forum and welcome to our community! I am happy to help here!
You are bringing up great questions! For the first one that you mentioned
“qwert” is mentioned as an example of consecutive characters: does this imply that all subsequent sequences of keys on a QWERTY keyboard (from left to right) are classified as “consecutive characters”? If yes, is this rule checked against other keyboard formats (Coleman, Dvorak)?
I am not able to see this anywhere in the documentation (Zoom Meeting API)
As fas as more documentation is available for Webinar or meeting passwords, I believe we do not have more documentation available and we do not have an endpoint that performs the validity of a passcode.
I will continue looking internally for more resources and will come back to you with an update.
Cheers,
Elisa
Hi @elisa.zoom
The point is that the “qwert” rule is mentioned in the password settings in the GUI as part of the flag related to consecutive characters, but not in the endpoints documentation (as you just showed).
After testing I see that rules for password with physically adjacent keyboard characters (“qwert”, “werty” and similar) are indeed enforced if the related flag is set.
So my point is: given this discrepancy between API documentation and the “qwert” rule mentioned (and applied if set) in the GUI, more insights on the actual perimeter of this extra rule are needed in case I need to check password validity in my app before trying to create a meeting.