Thanks @PhilipDAth for this feedback. I like what you've written about "more fundamental change" which we're excited to speak more about in the future, with a specific focus on enabling business outcomes and reducing the burden on the customer to manage API call budgets regardless of the apps they integrate. There are lots of options available to us, so stay tuned.
For the apps they're integrating, do you happen to know if they are leveraging ecosystem partners? We want customers to be successful with their integrations regardless of the number adopted, but are more equipped to support those from official ecosystem partners.
Re: the existing budget, which leads the industry by a fair margin (and keep me honest here), it's not usually obvious that increasing this number is the best area of investment. I'm happy to report that we see very few instances of customers consistently hitting their call budgets regardless of the number of integrations they deploy in a single organization, even with huge deployments. The data shows that the concerns about not realizing business outcomes are usually theoretical.
Whenever we hear "10 calls/second isn't enough" we want to make sure we understand the concern, and that usually means getting right down to specific scenarios where this pops up. We have worked closely with customers, partners and ecosystem candidates when the concern has been more acute, and we have observed that the current budgets are usually more than adequate to deliver the desired business outcomes. For example, for an org (864,000 API calls per day), even if that org uses four apps, that's 216K calls per app per org if and only if every app is trying to fully consume the budget all of the time or at the same time.
For what it's worth, sometimes the app simply isn't managing its budget effectively. This is a more common problem with apps from developers who are not in our ecosystem, but we've seen it even with other Cisco applications. It might not leverage the most efficient API calls for a given purpose (e.g. getDevice once per device rather than getOrganizationDevices once per org), or it might not cache any data locally, or it might call some operations far more often than necessary (e.g. running getOrganizationNetworks or getOrganizationPolicyObjects 10,000 times in a day for a single org). Some of these resources simply do not change that frequently even during active deployment operations. Or an application might not be leveraging the right API for the job (dashboard API is popular but we also have webhooks, scanning API, MQTT, etc.).
It's also important for ecosystem partners to be transparent with their customers about their budget consumption and provide built-in controls for the apps to rate limit themselves. Some of our partners even expose to the customer a configurable rate limit for their application to ensure that it plays nicely with the shared budget. But again, we want to reduce the burden on the customer to even care about API call budgets, so stay tuned.
