User API presense_status doesn't match documentation

When using the User API endpoint /users/{userId}/presence_status the information given only lists “Away,” “Available,” “Do_Not_Disturb,” and “Offline.” If you subscribe to the webhook events for presence updates, you get the full list that matches the documentation for the endpoint.

According to the documentation, the endpoint should have the same information available, but doesn’t seem to.

Is this a known issue?

Hi @sswany , thanks for bringing to our attention, we can submit for further inquiry with the API and respective documentation team. Can you share a screenshot of what you’re seeing?

Hi @gianni.zoom

This screenshot is for a user that’s currently in_calendar_event according to the webhook information, but this is what we get when using the api endpoint users/{user_id}/presence_status

Hi @sswany , so I do not believe “in a calendar event” and “do not disturb” are mutually exclusive. For example, I can have something on my calendar while I set my Zoom Chat to “do not disturb”. I can inquire further about the logic to see if chat presence overrides default calendar status.

Is the example you shared what led you to believe the this endpoint is only returning the following? Did the user set their chat status to do not disturb or are you saying they haven’t changed anything on chat and its’s returning DND even though it says in a calendar event on chat?

Hi @gianni.zoom

Your confusion is what lead to me posting this. Regardless of the actual presence_status the user currently has when using the /users/{userId}/presence_status endpoint, only a limited subset of statuses are returned that I mentioned.

If my status is currently “in_a_calendar_event” when using the endpoint, I get “Do_Not_Disturb” instead. Only when the status is updated via the subscribed webhook information do I get the true presence status.

There doesn’t seem to be a way to call the endpoint get the true status. The screenshot I sent was for a user that was actually “in_a_calendar_event” but that was what was returned.

Hi @sswany ,

I see! Thanks for those additional details. Can you please reproduce the requests and I will use the trace id for further investigation? Please send all the below requested details in this private message I’ll initate:

  • client id
  • developer email
  • API response
  • zm-tracking-id from API response header
  • screenshot of user status on chat client to show the discrepancy
  • webhook screenshot and id

Thank you Gianni. Just replied with the requested information.

Hi @sswany , this has been put into support for you where you will continue correspondence and escalations as needed (TS1538305). When concluded, please share your final updates in the thread. You can find notification of this in your email.