Description
We utilize two environments for Zoom, one is a local environment for development, the other is our production environment. Zoom is missing the option for allowing us to have a staging/testing environment which I always found strange.
I just received a message from Zoom that our marketplace app will be shut down because the development webhook can’t be validated (it can, it just requires ngrok to be running on our machine).
I’m wondering what the best practice is here.
How are we expected to develop features and fix bugs without a local environment option?
Why does the development webhook need to be validated anyway? Validations should be reserved for production or app submission.
Why when submitting an app update. The Zoom review team requires to test the development version of the app with the dev keys/secrets on production. This was the most bizarre request and really makes me wonder how you guys expect people to utilize the development environment in the marketplace ?
Our solution to this is just switching all of the marketplace development links to local when we need to make updates, and then having code on production that uses dev or production keys depending on the query string of the link. It’s a really dirty solution and doesn’t make sense or properly separate keys and environments.
Webhook validation will be released for all new webhooks created after Oct 23, 2022. All webhooks created prior to this date will not require validation unless you make changes to them. Webhook validation will be required for all new and existing webhooks as of October 2023.
We recommend using the development environment for staging/testing.
The development webhook needs to be validated to ensure we are sending webhook notifications to the owner of the app, and to ensure they aren’t intercepted by a bad actor.
We do require the development credentials and version of the app to be authorized, but can perform this test on a production site, staging site or development environment, as long as that environment has feature parity with the production user experience.
This solution is acceptable but not the only way possible. I don’t have specific guidance on how you could make it more to your liking but I’ll try to find other examples I could describe and follow up.
To answer your question about environments/credentials. I don’t think having more than 2 environments is necessary, I just wish one of them was allowed to be a dedicated local/development environment that does not need to be reconfigured constantly to satisfy requirements of your cron jobs and review cycles. My expectation was that the Zoom review team would be able to deploy a reviewer only production version of the app. This way they can test the new features/versions with the production credentials and on the production servers. In the current setup, how can your reviewers be sure that the thing they are testing and pushing to production will actually be the same set of features and functionality? It would be a simple thing to have a privacy friendly version for the reviewers, and then a privacy evil version for production since no one actually checks that (as far as I can tell?)
Zapier, for example, does not have a dev, staging or production environment. They just have versions, where only a single version is active (ie production), we can have as many versions as we want and each version has its own set of credentials. When a version is ready, we submit it for review and then it can become our active version when we are ready. in this case it creates a malleable format that can be modified to fit anyone’s development cycle.
In an ideal scenario with Zoom, we would have a team of people collaborating with the dev credentials on their local environments. Including working on bug fixes or features when we have a version pending approval… As it currently stands, development is ‘locked’ during the review cycle and the app admin has to swap the credentials and callbacks constantly. Even now development is “locked” as we are not actively developing a feature and want to avoid failed access to ngrok for development validation.
Can you share this message with me please?