Trouble Parsing JSON from webhooks on sub/connected accounts

Description

Having problems with the Recording Start and Recording Stopped webhooks events. For my question I am currently attempting to resolve an issue for a Webhook Only Zoom app.

In my API endpoint logs is the following error (Note: only getting this when sub accounts trigger the actions):

“Object reference not set to an instance of an object”

In the API I have setup a number of classes that match the respective schemas provided by Zoom. For the current project I utilize the “meeting.started”, “recording.started”, “recording.stopped”, and the “recording.completed” webhook events. When starting a meeting from my personal Pro Zoom account my server is able to receive and process the json that is POSTed to it without any issues (I am logging successful requests).

The problems begin when I replicate these zoom applications on a client’s Zoom account. The client has a Pro Zoom account with a number of connected accounts that it manages. Whenever I start a meeting, recording it, and end the meeting from a sub account the only successful web hook that I am able to process is the “meeting.started” webhook. For a while I was reviewing the errors in my local server logs and trying to figure out what the issue was. Later, I created a “Web Hook Only” Zoom app so that I could review the interactions taking place between the zoom server and my client’s server (from the perspective of Zoom via the Webhook logs).

The odd thing is that I would imagine that the meeting started event would fail to be processed from the sub accounts since their recording started and recording ended events causing internal errors on my server.

Any thoughts or ideas would be greatly appreciated as to how I can get the json processed from the webhook events of sub accounts. Feel free to message me if you need more details on what I’ve attempted so far.

TLDR

The main issue in a nutshell. Webhook calls originating from sub/connected Zoom accounts cause an internal error (500) on my client’s server for the recording started/stopped events even though they are not having issues when done so for the main account. I have experimented by temporarily giving these sub accounts developer permissions and even recreating the Zoom apps under their account logins manually.

I suspected that there may have been an error with my JSON mapping but the “meeting.started” events are being accepted on my side and they are being accepted when I use the main account as well as my own personal Zoom Pro account.

Error

The full error message or issue you are running into.

(Unable to parse webhook json from Zoom sub accounts)

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

The type of App was built to be a chat bot in case the client needs to send information to their server. This is also paired with a JWT app order to assist with the downloading of cloud recordings.

Currently all of the webhooks have been converted to a Webhook only app so that I can utilize the webhook logs.

Which Endpoint/s?

Endpoints are:

Recording Started, Recording Stopped, Recording Completed

How To Reproduce (If applicable)

See description text

Screenshots (If applicable)

NA

Additional context

Endpoint is written in c#

Hey @Rashid,

Can you share an example webhook JSON payload so I can reproduce this?

Thanks,
Tommy

Hey @tommy ,
Thanks for the message. Did you want me to post you the JSON from a failed called from my WebHook Logs under the App Marketplace dashboard?

Thanks

Good Morning @tommy,
Below is JSON pulled from the Webhook Logs of the Owner’s account. I have tweaked the JSON a tad bit in order to respect the privacy of the client but the changes should not change effect the behavior of the webhook calls. Let me know if you would like me to send you the actual URL of the endpoint we have set up and I can direct message it to you.

Thanks
JSON BELOW:

//“This is a recording.started event that is failing to be processed on the endpoint we have set up”
{
“applicationId”: “a5OE4HbKTr6GAWAEIIeftQ”,
“monitorTime”: 1596087665789,
“traceId”: “Webhook_34b5e55c198a41c191716e28e5e98a00”,
“accountId”: “ZseeX4ezQP-KO7QYdzbYsQ”,
“event”: “recording.started”,
“status”: “500”,
“userId”: “vKCb_IKYTgSIi5gtCTZyNQ”,
“url”: “https://www.clientwebsite.com/DesktopModules/ZoomBotApi/API/BotApi/RecordingEndpoint”,
“subscriptionId”: “0vNxJC7LTwO9B5xKKgX9yg”,
“requestHeaders”: “N/A”,
“requestBody”: {
“event”: “recording.started”,
“payload”: {
“account_id”: “ZseeX4ezQP-KO7QYdzbYsQ”,
“object”: {
“uuid”: “DxTm5lkdQDC8SV817gVlgw==”,
“id”: 7050215246,
“host_id”: “vKCb_IKYTgSIi5gtCTZyNQ”,
“topic”: “Client 7’s Personal Meeting Room”,
“type”: 4,
“start_time”: “2020-07-29T21:49:45Z”,
“timezone”: “America/New_York”,
“duration”: 0,
“recording_file”: {
“recording_start”: “2020-07-30T00:33:31Z”,
“recording_end”: “”
}
}
}
},
“responseHeaders”: {
“Content-Length”: “602”,
“Date”: “Thu, 30 Jul 2020 05:41:06 GMT”,
“Content-Type”: “application/json; charset=utf-8”
},
“responseData”: {
“Message”: "Object reference not set to an instance of an object. - STACK TRACE: at QS.Modules.ZoomBotApi.Classes.RecordingHelper.RecordingStarted(ZoomAPIDataShell zoomApiData) at QS.Modules.ZoomBotApi.Services.BotApiController.RecordingEndpoint(ZoomAPIDataShell zoomApiData) - FLAG: RecordingEndpoint(…) got content - {“Event”:“recording.started”,“Payload”:{“Account_id”:“ZseeX4ezQP-KO7QYdzbYsQ”,“Object”:null,“AdditionalProperties”:{}},“download_token”:null,“AdditionalProperties”:{}} ####content STRING#### QS.Modules.ZoomBotApi.Classes.ZoomAPIDataShell "
},
“runTime”: “330”,
“ttl”: 1597297268,
“requestParameters”: undefined
}

//“Below is a successful recording that is going to the same endpoint but is being handled successfully by our endpoint. This account is the owner account. The events appear to be failing on the managed accounts lower in the hierarchy.”

{
“applicationId”: “a5OE4HbKTr6GAWAEIIeftQ”,
“monitorTime”: 1596074559431,
“traceId”: “Webhook_448899aa280d4e6bb718fefbf4da4bf9”,
“accountId”: “ZseeX4ezQP-KO7QYdzbYsQ”,
“event”: “recording.started”,
“status”: “200”,
“userId”: “-TJaRrWtRK2yQXguHXCu3g”,
“url”: “https://www.clientwebsite.com/DesktopModules/ZoomBotApi/API/BotApi/RecordingEndpoint”,
“subscriptionId”: “0vNxJC7LTwO9B5xKKgX9yg”,
“requestHeaders”: “N/A”,
“requestBody”: {
“event”: “recording.started”,
“payload”: {
“account_id”: “ZseeX4ezQP-KO7QYdzbYsQ”,
“object”: {
“uuid”: “k4T3dqNZQECF9EEXfTyCYg==”,
“id”: 9961141221,
“host_id”: “-TJaRrWtRK2yQXguHXCu3g”,
“topic”: “Client’s Personal Meeting Room”,
“type”: 4,
“start_time”: “2020-07-30T01:48:55Z”,
“timezone”: “America/New_York”,
“duration”: 0,
“recording_file”: {
“recording_start”: “2020-07-30T02:02:34Z”,
“recording_end”: “”
}
}
}
},
“responseHeaders”: {
“Content-Length”: “21”,
“Date”: “Thu, 30 Jul 2020 02:02:38 GMT”,
“Content-Type”: “application/json; charset=utf-8”
},
“runTime”: “208”,
“ttl”: 1597284162,
“requestParameters”: undefined,
“responseData”: undefined
}

Hey @Rashid,

How are you handling the webhook request? The requestBody JSON is in the same format for each one. It must be an issue with your code.

Thanks,
Tommy

Hey @tommy ,
The odd thing is that of the four main webhooks that we subscribed for all of them work and are successfully processed by the endpoint on our end. It’s when the accounts managed by the main account are triggering webhooks that they are not able to be processed on our endpoint (The meeting started event usually is handled successfully though). I assumed that a “recording start” and a “recording ended” request would be handled the same no matter which account it was coming from ( assuming that the webhook was enabled for the specified account).

Any information or info concerning pitfalls that I could be possibly falling in would be greatly appreciated.
Thanks

Hi @Rashid, can you please test this with an account-level OAuth app, installed and authorized by an admin on both the main and sub account? This could help to isolate any differences in the access to these requests.

Can you provide the 500 error message that is returned?

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