This page (https://marketplace.zoom.us/docs/api-reference/rate-limits) states that:
Rate limits are applied at the account level. Rate limits will be shared by all apps created and installed on an account.
I’m trying to understand whose “account” this is referring to.
Is “account” referring to the account of the developer, the account of the user who is using the app or the entire organization which the user is a part of (i.e. aggregated across all users in that organization)?
If “account” is referring to the developer, won’t this put severe limits on the ability of an app to scale across many users?
Thanks for reaching out about this.
To clarify, rate limits are applied at the top level of an account/organization. So, an account (or organization, if you will) may have several different apps and app types, and the rate limits on each of these apps count towards the total usage. Keep in mind that our endpoints have specific daily limits in many cases as well.
Let me know if this helps to clarify—thanks!
Thanks, @will.zoom. So to be clear: the rate limit is based on the user’s organization (who has the app installed), not the developer’s?
In other words, it shouldn’t make any difference to the likelihood of the rate limit being hit whether 100 users are using the developer’s app or 10,000 users are using it?
I’ve seen conflicting answers about this on the forum (for example, this post implies that it’s based on the developer, not the user) and it’s really critical that we understand this.
Thanks for the reply—I definitely appreciate how important it is to be clear on the rate limits. I think some of the confusion might be around what constitutes an account. When I say account, I mean the account that your credentials are tied to. From our documentation: ‘Rate limits are applied at the account level. Rate limits will be shared by all apps created and installed on an account.’
Even if you have developer privileges on an account and have created an app in the marketplace, you’re still beholden to that account’s limit. Every request that is sent—and is associated with an app under the account—will count toward that account’s total allotment of requests. Credentials are tied to apps, so if there are several developers working under the credentials of a given set of apps, these are all still counted under the account which the apps were created under.
Let me know if this is a bit clearer.
Thanks @will.zoom. So just to confirm one last time (sorry to keep pursuing this - just want to be 100% sure), let’s say there are three companies:
- DeveloperCo - which has developed a Zoom API-based app (let’s call it ZoomApp)
- UserCo1 - which is a company which has installed ZoomApp
- UserCo2 - which is another company which has installed ZoomApp
If UserCo1 installs and uses ZoomApp, will it consume DeveloperCo’s API request allotment? Or will it consume UserCo1’s API request allotment?
Likewise, if UserCo2 installs and uses ZoomApp, will it also consume DeveloperCo’s API request allotment? If so, then am I correct in thinking that that means that every additional installation / use will consume more of DeveloperCo’s allotment and therefore put a cap on ZoomApp’s ultimate growth?
Thanks so much,
No worries, happy to clarify.
In your example, any usage of DeveloperCo’s app—by either UserCo1 or UserCo2 would be applied to the rate limits on DeveloperCo’s account, as that is the account that houses the app/credentials making the requests (on behalf of UserCo1 and UserCo2).
Let me know if you still have questions.
Hi, If my understanding is correct, isn’t this a deterrent to developers if it is they who bare the costs of scaling.
Surely it would be in the interest of all parties if the end-users themselves are the ones subject to limits. This, therefore, encourages developers to integrate with more apps, thus increasing the user base for Zoom.
The actions performed by User 1 should not, in my opinion, have any effect on the experience of other users. But with this model, as a system scales, this would easily occur as limits are applied.
In my personal case, users might be signing into my (the developers) app, but they sign in(Oauth) with ‘their’ credentials so they are accountable and surely they should be considered the ones making requests.
I hope I’m wrong.
@dave2 My thoughts exactly. If the limit truly works in the way that @will.zoom is describing, there is essentially a cap on how much a developer’s app could grow. It substantially diminishes the value of Zoom as a platform. Perhaps this is the intention - that if an app grows large enough to exceed a developer’s API limit, Zoom builds their own version of the app to displace it like Apple has done so many times
@matt5 - curiously I was looking at one of our competitor’s products who also have zoom integration. In their documentation, they do state that their users have a limit of 100 meetings a day. So this makes sense, and counters what @will.zoom is saying. As this means the limits are tied to the user signing in and not the developer. Go figure, so I’m still clear.
I appreciate the feedback and can understand how these kinds of limitations impact the flexibility you have when developing at scale. I will be sure to share this feedback with my team.
@dave2 regarding 100 meetings per day, 100 meetings can only be created or updated for one single userId in 24 hours. The 100-per day limit is tracked at the user level, not the application level.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.