Bug Report - since Monday 04/26 - Update meeting recording settings always fails password validation

Description
With the release last Monday 4/26 of:

“If an account owner or admin has enabled the “Recording password requirement” setting on the account settings page, the “password” field to access a recording must meet those requirements.”

Whenever I PATCH a meeting recording, say to simply add {“viewer_download”: true} without the password field being touched at all. I get this error back:

{“code”:300,“message”:“Validation Failed.”,“errors”:[{“field”:“password”,“message”:“The password you entered does not meet the password requirements.”}]}

This error triggers on any PATCH, even when I do actually try to set a password which more than meets the requirements.

Error
{“code”:300,“message”:“Validation Failed.”,“errors”:[{“field”:“password”,“message”:“The password you entered does not meet the password requirements.”}]}

Which App Type (OAuth / Chatbot / JWT / Webhook)?
JWT

Which Endpoint/s?
PATCH https://api.zoom.us/v2/meetings/{$uuid}/recordings/settings

I can provide a recording UUID and some curl commands if that would be helpful, I’m not sure what access you have to our account.

Hey @BenS,

Let me know if my post here helps:

Thanks,
Tommy

Tommy thank you for your response, I’m afraid it doesn’t help in this case :slight_smile:

We are aware that Zoom did change the default for recordings to have a password, we actually turned that back off for ourselves so it’s currently off.

The issue I’m bringing up is that if I try to update any setting for a recording, even if that setting doesn’t touch the password, even if password for the recording is turned off, the API call fails because of password validation.

This started happening not when you changed the default policy for all accounts a few weeks back, it started happening Monday 4/26 with the API update I pointed to.

No doubt it’s a result of some interaction between that API update and maybe the new default you bring up, but I’m pretty darn sure it’s a actual bug :).

Thank you for looking into it.

FIXED,

can’t reproduce today, looks like it was fixed in subsequent API updates, one on 4/29 looks like it could be responsible for the fix.

1 Like

Happy to hear it is working now @BenS! :slight_smile:

Let us know if anything strange like that happens again or if you have additional questions.

-Tommy