Is your feature request related to a problem? Please describe.
There’s not really a problem, but let me describe why it makes sense to do so in my opinion, and should not be hard to implement on the Zoom backend at all (since the client_type is already part of the user.signed_in event which fires right before opening the mobile app, etc.). Opening the mobile app triggers a user.signed_in event followed by a presence event: user.presence_status_updated to Available – also, because the Zoom app is (often) closed in the background or out of the active memory on your mobile device when you get a message and you have it set to send mobile notifications, there will be an automatic user.signed_in/user.presence_status_updated event. At first, this was a bit misleading because it looks like the user is actually active, but it’s simply the app having to sign-in to deliver the push notification. Having the client_type parameter (which is already on the user.signed_in event) as part of the payload to the user.presence_status_updated event makes a lot of sense because one can differentiate between such a state.
Describe the solution you’d like
Pretty simple 
!
Add/expose the (already existent) client_type parameter in the user.presence_status_updated webhook event (which should not be hard to do at all).
Describe alternatives you’ve considered
There’s not much in the terms of alternatives; the only thing you can do is messy and cannot be fully reliable. You could monitor the user.signed_in event that fires right before the user.presence_status_updated event, get the client_type from the sign-in event, check if it’s iphone or android, and then add a threshold (because they fire right after one another). However, that’s really not a clean way to do it and adding the client_type parameter to the user.presence_status_updated event is the proper way to do it.
Additional context
I can provide screenshots if necessary, but I think this simple feature request speaks for itself.
