App Submission Clarifications (staging vs production, login permissions, and long polling)

App Marketplace
1

Description
I have submitted a Zoom application and had a few clarifying questions about the review process. Much of this has come out of reading the recommended blog article (https://medium.com/zoom-developer-blog/how-to-get-your-app-published-to-the-zoom-app-marketplace-on-your-first-review-7d5c97b78d1a) and reading over other forum entries here.

High level questions
1 - Are app submissions using staging.domainname.com instead of domainname.com ok?
2 - How does tester know to use staging deauthorize URL?
3 - Definition of long polling?

1 - Are app submissions using staging.domainname.com instead of domainname.com ok? How does tester know to use staging deauthorize URL?

I ask this question because our app has a staging and production environment. I have submitted the application with the staging.domainname.com as the starting point for our tester to test on. The functionality is not available on our production environment, because, of course, due to our app not being published on the marketplace no one can log in to Zoom besides us.

2 - I also want to inquire about how the tester will know how to test the deauthorization URL when you are only allowed to provide one in the App Information.

I would have hoped that you would have been able to enter a deauthorization url for the testing environment, and one for the production environment (similar to how you can enter a Redirect URL for OAuth that is different between both environments). Because only one URL is allowed in the App Information configuration, I have put the production URL - but the tester will need to use the staging URL as that is where they will be testing. Is this ok?

3 - Definition of long polling?

After a user logs in with Zoom in our app, they are taken to a page where they see their meetings. Each time a user visits this page, we request a user’s meetings from the Zoom API. We do not ever get meetings from the Zoom API outside of this. I hope this does not qualify as long polling, but wanted to confirm.

Feel free to reach out to me via DM or email if more useful - I have logged in with same email tied to my App submission, thanks!

2

Hey @okzoomer,

The production version of your app will be tested during the review. However we can clarify this during the app submission process.

This will be communicated during the testing process.

Long polling means hitting the API for data to generate reports when you could use the respective webhook to do so without hitting the API.

Thanks,
Tommy

3

@tommy Thanks for the response.

The production version of your app will be tested during the review. However we can clarify this during the app submission process.

This will be communicated during the testing process.

All the URLs I’ve provided in the release notes and the login page URL set up are on the staging domain - is that sufficient information for the reviewer to understand that they must use a reauthorization identical to the production one (except with the staging domain)? Or do I need to withdraw the application and re-submit again?

Long polling means hitting the API for data to generate reports when you could use the respective webhook to do so without hitting the API.

I’m not sure that clarifies things for me - can you speak to whether the use case I mentioned in my original posts qualifies?

4

Hey @okzoomer,

Please use your production domains because if your app was approved, you would have to make an update request anyway, where in total we would have had to review your app twice.

It will be faster if you submit with your production domains.

Your use case is fine! :slight_smile: Not considered long pulling. An example of long pulling is running nightly reports making tons of API requests when you could just use the webhooks to get that data.

Thanks,
Tommy