Turbonomic uses APIs. We can contribute to Azure API throttling. How do we manage and minimize this impact.

Many clients have multiple applications using API calls in Azure Subscriptions. Security Apps, Compliance Apps, APMS (like Dynatrace) , Terraform, and our IBM apps - Turbonomic ARM and parkmycloud (PMC). Whilst Turbonomic may not be the main consuming of API Calls the current limit per sub per hour according to Microsoft is 28000. Only they can run queries determining which applications are consuming this 28000. After the 28000 is consumed, no more API calls for that Subscription is allowed. This can have a negative impact in 2 ways 1) turbonomic has incomplete data to make recommendations. Clients are tracking our recommendations and don't like inconsistency. It reduces trust. 2) other applications start getting errors - and they'll ask for other competing apps to be removed. e.g. a Client asked us to remove Turbonomic from SAP Prod Subs. SUGGESTIONS : Turbonomic API calls to Microsoft should follow Microsoft's recommendations for efficiency - found here -> https://docs.microsoft.com/en-us/partner-center/develop/api-throttling-guidance. Which I'm sure we're already doing. Are there ways to synchronize Turbonomic's API calls to particular times of the day? Terraform can do their deployments in the morning, and Turbo runs the storage probe in the afternoon? Can Engineering reduce the number of API calls per hour for certain targets (depending on business value). Can you make this adjustable by the customer in Targets. Can we actually count the number of API calls we're making so that we can self police - if for instance we're adding a lot of API calls like adding PMC to the mix. Can we analyze and find out which of our probes or targets are causing lots of API calls and prioritize them by business value? And show that in the tool I'm not a developer but the process is ALREADY murky because only Microsoft can see the limits and API usage. This is an interesting business problem. What are Microsoft working on to better fix or manage this issue? I've scoped this to Azure right now - but I'm sure similar things apply to AWS.