I run a project that uses the Zoom API that supports students viewing lectures/class meetings that were recording on Zoom.
Currently there is no way to pin your project to a stable version of the Zoom API. Version 1 of the API is no longer in use, and Version 2 is currently being developed on.
The issue is that any time there is a release on Version 2 this potentially changes the API calls that we are making in production in our project. It has happened many times that our project breaks because of a change in the Zoom API and we need to rush to push out a fix. And over time the Zoom API has improved a lot! But…
Yes, there are release notes, but there’s no way for us to know which changes are coming in advance so that we can test them with our project.
It would be great if we had versioning within version 2 of the Zoom API so that we could use a stable version of the API in our project. Then, when a release happens we could test it in our development environment, and then update our production environment to use the latest version of the API once it has been tested thus hopefully avoiding major failures in production.
Let me first start by saying thank you for reaching out and that on behalf of Zoom we understand the trouble this caused you and are taking this post very seriously.
As we grow, we have needed to think about how we scale and this is a swift kick in the pants to remind us how important it is. So, saying that, I would love to learn more about what broke and how it broke. This way we can learn from that mistake and mitigate cause in the future.
We have already started an internal discussion about how to mitigate these as a whole, and I will share with you (within a week) what we plan to do from a process standpoint to reduce these kinds of breaks in the future.
Please know that we are on it and thank you again for reaching out!
The thing is, it’s not really about what specific changes are made in Zoom API updates, rather it’s about being able to use a stable version of the webhook where we can have control over when those changes happen and test them before we release them into production in our own system. Although I try to write resilient code, it’s impossible to use the API without making assumptions about how it behaves based on past behavior and you can’t possibly know which fields or behavior I am depending on therefore the only way to permanently solve this problem is to use versioning.
