Created type 2 meetings don't return password

Description
I have enforced all instant and scheduled meetings to require passwords and one-click URL support. My goal is for Zoom to pass meeting passwords through the API and not have to worry about password creation. This currently works for type 1 meetings, where I don’t have to pass the password parameter, but a password is created and is returned to me. However, for type 2 meetings, I attempt the same call, just modifying the meeting type, and no password is returned. PMIs are not in use for scheduled meetings.
What is different about type 2 meetings? Why would the type 1 meeting return a created password but 2 would not? Any suggestions?

Error
No password created for type 2 meetings.

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

Which Endpoint/s?
https://api.zoom.us/v2/users/{userId}/meetings

Summarized body of POST
topic = “TestMeeting”,
type = 2,
startTime = “2020-05-14T16:45:00”,
duration = 30,
timezone = “America/Denver”

Return
“topic”:“TestMeeting”,“type”:2,“status”:“waiting”,“start_time”:“2020-05-14T22:45:00Z”,“duration”:30,“timezone”:“America/Denver”,“created_at”:“2020-05-14T19:25:05Z”,“start_url”:“https://zoom.us/s/{meetingId}?zak=… 2532158782”,“type”:“toll”,“country”:“US”},{“country_name”:“US”,“city”:“Houston”,“number”:"+1 3462487799",“type”:“toll”,“country”:“US”},{“country_name”:“US”,“city”:“San Jose”,“number”:"+1 6699006833",“type”:“toll”,“country”:“US”},{“country_name”:“US”,“city”:“Germantown”,“number”:"+1 3017158592",“type”:“toll”,“country”:“US”},{“country_name”:“US”,“city”:“Chicago”,“number”:"+1 3126266799",“type”:“toll”,“country”:“US”},{“country_name”:“US”,“city”:“New York”,“number”:"+1 6468769923",“type”:“toll”,“country”:“US”}],“registrants_email_notification”:true,“meeting_authentication”:false

Hey @InfoAdam,

Let me know if this thread helps:

Thanks,
Tommy

Thanks for the reply, @tommy. Meeting passwords are required and enforced, as well as the one-url option.

@Tommy let me clarify that, those options were already enabled prior to your suggestion. The API call still doesn’t return the password for type 2 meetings.

Hey @InfoAdam,

I just tested and the Create Meeting API returned a password without me setting one in the request body.

Here is my Account Level password settings (I am not using PMI for scheduled meetings):

Request body:

{
"topic": "Test without setting password in api call with account level settings locked",
"type": "2",
"start_time": "2020-06-08T10:00:00",
"duration": "30"
}

Response body:

{
    "uuid": "[redacted]",
    "id": 123456789,
    "host_id": "[redacted]",
    "topic": "Test without setting password in api call with account level settings locked",
    "type": 2,
    "status": "waiting",
    "start_time": "2020-06-08T16:00:00Z",
    "duration": 30,
    "timezone": "America/Denver",
    "created_at": "2020-05-28T22:40:51Z",
    "start_url": "[redacted]",
    "join_url": "[redacted]?pwd=eDNVSzYxcFRCaEduRVAxOEVNQnhDdz09",
    "password": "599855",
    "h323_password": "599855",
    "pstn_password": "599855",
    "encrypted_password": "eDNVSzYxcFRCaEduRVAxOEVNQnhDdz09",
    "settings": {
        "host_video": true,
        "participant_video": false,
        "cn_meeting": false,
        "in_meeting": false,
        "join_before_host": false,
        "mute_upon_entry": true,
        "watermark": false,
        "use_pmi": false,
        "approval_type": 2,
        "audio": "both",
        "auto_recording": "none",
        "enforce_login": false,
        "enforce_login_domains": "",
        "alternative_hosts": "",
        "close_registration": false,
        "registrants_confirmation_email": true,
        "waiting_room": false,
        "global_dial_in_countries": [
            "US"
        ],
        "global_dial_in_numbers": [
            {
                "country_name": "US",
                "city": "San Jose",
                "number": "+1 6699006833",
                "type": "toll",
                "country": "US"
            },
            {
                "country_name": "US",
                "city": "Houston",
                "number": "+1 3462487799",
                "type": "toll",
                "country": "US"
            },
            {
                "country_name": "US",
                "city": "Tacoma",
                "number": "+1 2532158782",
                "type": "toll",
                "country": "US"
            },
            {
                "country_name": "US",
                "city": "Chicago",
                "number": "+1 3126266799",
                "type": "toll",
                "country": "US"
            },
            {
                "country_name": "US",
                "city": "New York",
                "number": "+1 9292056099",
                "type": "toll",
                "country": "US"
            },
            {
                "country_name": "US",
                "city": "Germantown",
                "number": "+1 3017158592",
                "type": "toll",
                "country": "US"
            }
        ],
        "registrants_email_notification": true,
        "meeting_authentication": false
    }
}

One thing I noticed while testing, if you do not lock the “Require password when scheduling new meetings” account level setting, and you make a request to create a meeting without setting the password, example:

{
"topic": "Test without setting password in api call with account level settings locked",
"type": "2",
"start_time": "2020-06-08T10:00:00",
"duration": "30"
}

You are essentially not checking the password like when creating a meeting through the Zoom Web Portal:

So the password will not generate and be returned in the Create Meeting API response.

NOTE: In the future, passwords will be enforced on for all accounts, so if you do not set a password when calling the create meeting API, it will always generate and return one for you.

Let me know if that helps! :slight_smile:

Thanks,
Tommy

2 Likes

Hi @tommy!

We have an OAuth app on the marketplace which creates meetings on users’ behalf. We were assuming that from May 30th, all the API requests to Create an Instant Meeting (meeting type = 1) would return a password in the response.

Just yesterday, we found that one of the meetings created via the OAuth app (installed on an external user’s Zoom account) did not have a password. Could you please explain why that may be?

If it helps, the Zoom account was an enterprise account with the meeting join url beginning with https://<EnterpriseAccountName>.zoom.us/j/... instead of https://zoom.us/j/...

Thanks for all the help!

Hey @moogway,

Happy to help! The password update actually changed, you can review the new plan here:

Thanks,
Tommy

Thanks @tommy for pointing to the blog post. According to it, a meeting cannot be created without a password. That is exactly how we’ve configured the application to work. Our OAuth API sends a password in the create meeting API request and expects a hashed version of the password returned in the response (along with a pwd field in the query params of the join_url).

In the create meeting API request in question (the one I am talking about), the response returned a null value in encrypted_password field and the join_url also didn’t have a pwd field in the query params. This, technically shouldn’t happen (as per Zoom’s security updates and the blog post).

So we are trying to figure out the cases in which this is likely to happen so we can account for it in the app code.

The only possible reason we have right now is that maybe the security updates have not been enforced for Zoom Enterprise Accounts (ones with vanity URLs, which begin with https://<vanityUrlSubdomain>.zoom.us/) because everything else has been the same and the create meeting request works flawlessly for Zoom Pro and Basic accounts.

If you could shed any light on why the Create Meeting API request would return a null value in the encrypted_password field, it would help us tremendously in mitigating this possibility. Could it be a Meeting Security Configuration issue? Or does it have something to do with the user’s type of Zoom Account (e.g. Enterprise Accounts can create meetings without a password but Pro and Basic Accounts cannot)?

Looking forward to your response.
Thanks

@moogway: Have you locked the password setting?

1 Like

@stephane.lux Thanks for the pointer. But as per the thread you have referenced, if the password setting is not locked, sending a password in the “Create meeting” request (as we are doing) should return the created meeting data with the encrypted joining password. Am I missing something here?

@moogway I have the setting locked and I receive an encrypted joining password when creating a meeting with a password. I don’t know if locking the setting is required, but you can give it a try, to see if is related.

1 Like

Thanks again @stephane.lux. So here is the behaviour as per few of the tests we ran -

  1. Basic Account - Setting locked or unlocked, created meeting response has a password even if a password is sent/not sent in the Create Meeting request
  2. Pro Account - Setting locked or unlocked, created meeting response has a password even if a password is sent/not sent in the Create Meeting request

Essentially, it seems to me that the request response always has the password irrespective of whether the setting is locked or unlocked or whether a password is communicated or not, at least in the case of Basic and Pro Accounts. Am not sure of Enterprise accounts at this moment. Will keep testing more, I guess

Thanks for contributing @stephane.lux! :slight_smile:

@moogway, anything I can clear up for you?

-Tommy

Thanks @tommy! I still don’t understand why some of the created meetings are not returning a password. According to the blogpost, 15th July onwards all the created meetings will have a password for sure.

Is that a correct assumption?

Hey @moogway,

We have actually extended the time to September 27th to give developers more time.

We will get the blog post updated asap.

Thanks,
Tommy