Updating a user is now deleting the host key following 12.21.20 update

Description
I think this latest API update may have introduced a new bug. After issuing a request to the PATCH /v2/users/{userId} endpoint, the host_key field for that user got erased even though it was not included in the request. This didn’t happen prior to the update.

Error
The full error message or issue you are running into.

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

Which Endpoint/s?
PATCH /v2/users/{userId}

How To Reproduce (If applicable)
First issue a GET user request. This responds with a user object that has a host key value:

{
  "account_id": "redacted",
  "cms_user_id": "",
  "created_at": "2020-12-07T02:59:21Z",
  "dept": "",
  "email": "redacted",
  "first_name": "Chris Peoples-Irvine, CA",
  "group_ids": [
    "j-cS5lkvQ1KAGiKDjG_LOA"
  ],
  "host_key": "666245",
  "id": "redacted",
  "im_group_ids": [],
  "jid": "",
  "job_title": "",
  "language": "",
  "last_name": "",
  "location": "",
  "login_types": [
    99
  ],
  "personal_meeting_url": "https://zoom.us/j/8560425100",
  "phone_number": "+null ",
  "pmi": 8560425100,
  "role_id": "2",
  "role_name": "Member",
  "status": "active",
  "timezone": "",
  "type": 2,
  "use_pmi": false,
  "verified": 1
}

Then issue a PATCH to change the first name:

PATCH https://api.zoom.us/v2/users/vor.sandbox.001@otahq.com

Headers:
  Authorization: Bearer redacted
Content-Type: application/json

Body:
  {
  "account_id": "redacted",
  "cms_user_id": "",
  "created_at": "2020-12-07T02:59:21Z",
  "dept": "",
  "email": "redacted",
  "first_name": "Update First Name",
  "group_ids": [
    "j-cS5lkvQ1KAGiKDjG_LOA"
  ],
  "id": "redacted",
  "login_types": [
    99
  ],
  "personal_meeting_url": "https://zoom.us/j/8560425100",
  "phone_number": "+null ",
  "pmi": 8560425100,
  "role_id": "2",
  "role_name": "Member",
  "status": "active",
  "timezone": "",
  "type": 2,
  "use_pmi": false,
  "verified": 1
}

Then do another GET on the same user. Now host key is blank:

{
  "account_id": "redacted",
  "cms_user_id": "",
  "created_at": "2020-12-07T02:59:21Z",
  "dept": "",
  "email": "redacted",
  "first_name": "Update First Name",
  "group_ids": [
    "j-cS5lkvQ1KAGiKDjG_LOA"
  ],
  "host_key": "",
  "id": "redacted",
  "im_group_ids": [],
  "jid": "",
  "job_title": "",
  "language": "",
  "last_name": "",
  "location": "",
  "login_types": [
    99
  ],
  "personal_meeting_url": "https://zoom.us/j/8560425100",
  "phone_number": "+null ",
  "pmi": 8560425100,
  "role_id": "2",
  "role_name": "Member",
  "status": "active",
  "timezone": "",
  "type": 2,
  "use_pmi": false,
  "verified": 1
}

Screenshots (If applicable)
If applicable, add screenshots to help explain your problem.

Additional context
Everything seemed to be working fine prior to today, but now the host key is missing after an update.

Hey @chris.ota,

Thank you for reaching out to the Zoom Developer Forum. I’ve since reached out to our engineering team in regard to this issue. I’ll be sure to update you when I have more information. (ZOOM-230308)

Thanks,
Max

@MaxM I’m experiencing the same issue, is there any status update?

Chris, I’m following the exact same pattern of creating a PATCH payload by modifying the response from a GET to the users/:id endpoint, and started seeing 400’s on the PATCH response with a code that the host_key field failed validation.

One confounding issue is that I can still see the host key if I log into the user’s Zoom account. I’m not sure why that is coming back empty from the GET request, and I suspect that’s the underlying bug - the field missing in the response, rather than somehow getting wiped out in the PATCH.

In my case, doing a partial PATCH to the user seemed to work - I’m just sending up a payload with { first_name: 'Lorem', last_name: 'Ipsum' } without issue, and without effected any of the other fields (so far as I’ve tested)

I noticed something similar. Once a user’s host_key got to an empty state, if I viewed that user in the Zoom admin, it would regenerate the host key. Very weird.

Hey @chris.ota and @timw,

Thank you for providing more information on the issues. Our engineering team reported that they were unable to reproduce the issue and asked that you try the call again. Based on what you’re both saying, it sounds like you are still encountering the issue. I’ve since reached out to our engineering team with this information to assist in the investigation.

I’ll be sure to keep you posted.

Thanks,
Max

Hey @chris.ota,

Our engineering team got back to me and requested more information. Are you able to provide the userId involved as well as the request body and endpoint you’re using when you see that the host_key is missing?

Thanks,
Max

Hi @MaxM,

I won’t have time to try it again until next week, but I was initially able to reproduce the issue with multiple users, and with both fully licensed users and API users. Request body and endpoint are in my original post.

Hey @chris.ota,

Thank you for your response, I’ll be sure to update our internal team with the endpoint that you’re using when I have the userId.

Thanks,
Max

Hey @chris.ota,

Thank you for your patience. Our engineering got back to me and indicated that they’re seeing the Update a User API and Get a User API are being called very frequently in a short amount of time.

They saw a call to the Update a User API followed very quickly by 100 calls to the Get a User API. Are you making these requests in a loop or do you have a high volume of calls that may come in at one time? Our engineering team advised against making the calls so quickly in order to avoid this issue.

I hope that helps! Let me know if you have any questions.

Thanks,
Max

Hi @MaxM,

Are you seeing 100 Get a User API calls for the same user, or different users? Different users makes sense because we could 100s of users joining a webinar at roughly the same time. If it’s the same user, I’ll need to investigate why that’s happening.

Hey @chris.ota,

That’s a good question, I’ve reached out to our engineering team to see if they can confirm this. In the meantime, would you be able to use a Webhook-only app to receive webinar.participant_joined event?

This webhook doesn’t include the host_key (although we could submit a feature-request for that) but it would reduce how often you have to call the Get a User API and may help to resolve the issue you’re seeing.

Thanks,
Max

I’ll look into using participant_joined webhook, but I’m not sure that will be viable because I’m calling Get a User API before they join the webinar. I’m not actually using host_key so that wouldn’t be an issue.

I’m also wondering if the burst of calls the engineers are seeing is a result of my integration tests. Hmm…

Hey @chris.ota,

Thank you for the update. I’ll keep you posted on what I hear from our engineering team in regard to these requests.

Thanks,
Max

Hey @chris.ota,

Thank you for your patience. Our engineering team got back to me and indicated that they saw the requests were all for one user.

I hope that helps!

Thanks,
Max

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.