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:
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.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
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.
I can provide screenshots if necessary, but I think this simple feature request speaks for itself.