V2 Webhooks Notifications understanding


#1

 

Hello,

We are testing the new V2 Webhooks and we are having problems with the new notifications, in fact “participant_joined” notification.

We are receiving this notification firstly when a Host joint the room. But after that we are receiving again the notification 4 times.

This is the body received for these repetitive notifications: 

{``"payload"``:{``"meeting"``:{``"uuid"``:``"q8nwXFwxRUGAd9G0sK9xXg=="``,``"participant"``:{``"user_id"``:``""``,``"user_name"``:``"MRA-204.141.31.37"``,``"join_time"``:``"2018-02-07T11:31:00Z"``}}},``"event"``:``"participant_joined"``}

You can check the Webhook logs on my account. Anyway I made a summary of the different notifications of a meeting to explain you the whole flow: 2018-02-07 12:30:59 POST 200 -> Meeting started 2018-02-07 12:31:02 POST 200 -> participant_joined (Host) 2018-02-07 12:31:03 POST 200 -> participant_joined (we don't know what it is) 2018-02-07 12:31:03 POST 200 -> participant_joined (we don't know what it is again) 2018-02-07 12:31:03 POST 200 -> participant_joined (we don't know what it is one more time) 2018-02-07 12:31:03 POST 200 -> participant_joined (we don't know what it is and one more time) 2018-02-07 12:31:36 POST 200 -> participant_joined (participant entered into the Zoom meeting) 2018-02-07 12:32:06 POST 200 -> meeting_ended 2018-02-07 12:32:42 POST 200 -> recording_completed

We were told from Support Team that this repeated notification is related to the cloud connector. But it would be possible to avoid receiving this notification as far it is not really useful to manage the notifications?

Thank you very much,

 

Best regards,

 

David Pereira


#2

@David, this maybe a bug of participant_joined event, we will check and fix it ASAP.

Please ignore this notification first, thanks.


#3

@harris Ok thank you. Please keep me updated :slight_smile:


#4

Hi @harris,

Any update on this? 

Could you please tell me if this will be fixed on next release? If so, when will it be deployed the fix? 

Thank you


#5

Hi David, yes - we will fix this - ETA is first week of March.  Till then, if you want to continue to test, please ignore  MRA ("user_name"``:``"MRA...) - it's not a valid attendee.

Regards, Wei 


#6

Thank you for the information Wei.

In addition, could you please add the id of a meeting to the participant_joined event? If you could add the host_id also it would be perfect.

Now we are receiving this information:

 

I ask for the id of a meeting because we need the meeting information to integrate this notification. Now with the notification we are receiving only the UUID. We cannot use this UUID to retrieve the meeting info (https://zoom.github.io/api/#retrieve-a-meeting needs the ID, not the UUID). Also, we cannot look for this UUID retrieving the List of meetings by Host_ID because we are not receiving it on the notification. 

This request is the most urgent right now because without this kind of information we cannot integrate this notification into our system. Please let me know if it could be possible to release this before March. 

Thank you in advance,

Kind regards,

David Pereira


#7

@David, we will consider to add “id” and “host_id” parameters to this notification, but can’t release this before March. Now you can get the end meeting information via UUID. Please refer to https://zoom.github.io/api/#retrieve-meeting-detail


#8

Thank you @harris Just to confirm one thing about your UUIDs.

We discarded to use them because their format is not really an UUID. For example, we receive sometimes this kind of UUID with a slash inbetween

If I use this UUID as a route param on a request, it will fail because this request is being like a two params requests. Maybe we can convert this UUID, or encode it or something else but we think that is not the right way to do it. 

Also we discarded because this UUID is not following the UUID standard format: https://en.wikipedia.org/wiki/Universally_unique_identifier

Do you have any workaround for this case?

Thank you

David Pereira


#9

@David, please test this API call with UUID. We’re dealing with this particular value in url format.


#10

@harris We’ve already tested it and it’s not working, when we use a UUID with slash it sends a 404

If the UUID hasn’t got any slash, we receive this:


#11

@David, please check if your account have Dashboard feature?


#12

@harris Thanks for your help,

Our sub-accounts that we are using have the API Plan. So, if the dashboard is included in API plan, we have it. Otherwise, we don’t.


#13

@David, you can go to your sub account to check if have Dashboard feature, if not, please ask our Zoom Support to enable it for your sub account.


#14

Hi,

Any update on this Wei and Harris?

If you could give us some details on ETA for next release or whatever it would be great. We are blocked by this and we are running out of time. We talked to your CTO and he told us that the best place to report bugs is the community forums.

Thank you,

David


#15

David, please see the post that put out yesterday - the fix for the participant join/leave is now available. please test it out. 

 

Wei @ Zoom


#16

Hi again,

But we are still receiving the UUID as I told you in a message here 14 days ago. We explained why we cannot use the UUID and we understood that you were considering to include the ID of a meeting and the HOST_ID for that meeting.  

Could you give us more details if this will be deployed or not? 

Thank you


#17

@David, please check the previous comment:

@David, we will consider to add “id” and “host_id” parameters to this notification, but can’t release this before March. Now you can get the end meeting information via UUID. Please refer to https://zoom.github.io/api/#retrieve-meeting-detail

We will plan to support this feature in the next web release. 


#18

@Harris, Thank you. Do you know exactly the ETA for this web release?


#19

@David, sorry, I don’t know the exactly date, only know about May.


#20

@Harris, Sorry, do you mean May or March? Because on your previous message you said: “(…) but can’t release this before March”. 

We cannot wait until May for just a new property on the payload…