I am trying to build a system for ingesting our zoom recordings initiated by a webhook endpoint that receives RECORDING_MEETING_COMPLETED events.
Today we noticed that the payload of the webhook requests has changed dramatically and now includes much more than just the event type, host_id and uuid (but no longer has an “id” field). The serialized json passed in the “content” parameter now includes more info about the meeting as well as a list of the recording files. It now looks similar to the response we get from a v2/meetings/{meetingId}/recordings request, but the recording_files entries include a s3 “file_path” value instead of “play_url” and “download_url”.
We are confused and concerned by these changes. It was our understanding that the RECORDING_MEETING_COMPLETED was going to be made more consistent with the other event types. This latest change does not do that and instead extends the existing inconsistency.
Should we expect further changes to the webhook functionality? We have operated under the assumption that the v2 API was somewhat unstable, but the webhook functionality has been around and was, we thought, distinct from the API.
We built our webhook endpoint using logic from the example at https://gist.github.com/joshuawoodward/35ee7f4b220f88b6559587cb9fbdab02. Is that no longer the recommendation?