Microsoft is introducing daily API call limits in the October licensing:
https://docs.microsoft.com/en-ca/power-platform/admin/api-request-limits-allocations
This will affect all user accounts, all types of licenses, all types of applications/flows. Even non-interactive/application/admin user accounts will be affected.
This may give you a bit of a panic attack when you are reading it the first time, but there are a few things to keep in mind:
1. There will be a grace period until December 31, 2019
You also have an option to extend that period till October 1, 2020. Don’t forget to request an extension:
This grace period applies to the license plans, too.
2. From the WebAPI perspective, a batch request will still be counted as one API call
Note: as of December 2019, this is incorrect (a note added in June 2020). For the details, check this out: https://www.itaintboring.com/dynamics-crm/spooky-scary-licensing-caught-up-with-me-again/
Sure this might not be very helpful in the scenarios where we have no control over how the requests are submitted (individually or via a batch), but, when looking at the data integrations/data migrations, we should probably start using batches more aggressively, especially since such SSIS connectors as KingswaySoft or CozyRoc would allow you to specify the batch size.
Although, you may also have to be careful about various text lookups, since, technically, they would likely break the batch. From that standpoint, “local DB” pattern I described a couple of years ago might be helpful here as well – instead of using a lookup, we might load everything into the local db using a batch operation, then do a lookup locally, then push data to the target without having to do lookups there:
https://www.itaintboring.com/dynamics-crm/data-migration-how-do-you-usually-do-it/
3. Those limits are not just for the CDS API calls
Thanks for the extra information, Alex. Where did the information on grace period come from? You’d think that should go in the original article. I was wondering about the batch thing also, I am presuming (hoping) this also applies to the ExecuteMutliple method of the .NET native libraries. Between those two items this should make this change a bit more manageable with our customers than how it initially looked.
The grace period was mentioned in the Office 365 message center announcement last week. It was not clear whether it would be applicable to the plans only or to the API limits as well, but, at this point, I believe it’s both, and those details will likely be added to the licensing FAQ soon. From the API call count standpoint, ExecuteMultiple was always considered to be 1 call, same as batch, so I’m pretty sure it’s going to be the same interpretation this time, too.
I really don’t understand how Microsoft thinks these limits will allow anyone to do anything of worth. At the highest tier of 20,000 API calls per 24 hours, this equates to just shy of an average of 14 API calls per minute. This is really quite pathetic. They are literally going to kill the concept Dynamics 365/PowerApps as a development platform with this change. Different development techniques like batch requests will only help a little, with such anemic numbers I can only hope they rethink this plan. The only reason I can think of why they’re putting in such low limits is because they’re trying to go extremely high density in their server hosting, which would be a nice cost saving approach on their part, but the cost/impact to the consumer here is far too high.
Hey Alan, I am not sure it’s that bad. If it’s correct that we won’t be hitting those limits during normal use, and, I think, that’s what Microsoft is assuming based on their telemetry, then it’s the integrations that we should be concerned about. This is where batch requests should help more, though (although, I have some reservations on that, since, from the server-side perspective, batching might help to reduce load requirements on the service endpoint, but all those requests within the batch still have to be processed. Seems reasonable there should be some limits, too)
It’s a number per user, which seems quite fair
Alex –
Question regarding Non-licensed users/application users.
“Request limits are applicable to these users, like licensed users. By default, since these users do not have any licenses assigned to them, they are allocated zero requests.”
Does this mean that the application user accounts are to be used ONLY for authentication?
And for any kind of API calls, they need a paid license?
Hi Shidin, basically yes, though you will be able to assign (a paid) API calls add-on to those user accounts through the admin interface, so it’s not necessarily a license you’ll need to assign to them
Our text lookup features uses very limited number of service calls, unless you have chosen a wrong cache mode.
Does these limits apply to portal users (contacts) making API calls as SYSTEM user.? It won’t take many users to reach that limit very quickly.
My understanding is that SYSTEM plugins won’t count (yet?). Portal will come with it’s own granted API capacity, but if, somehow, you go above that, you will be able to assign additional capacity through the add-ons
Hey Alex,
it’s kind of interesting to see how this works with big integrations happening on a daily base. We have a customer which is importing up to 20000 transactions a day. and for those transactions we have business logic running, which is transforming data based on other data in crm. So batching in those scenarios is kind of difficult?!
And then we have other customers which are having millions of contacts in their database and all of them are valuable not only garbage. At a certain time in the year their are doing marketing campaings for all of them, which is about exporting data and protocolling the activity => all API-Requests.
So I m kind of now wondering if we have just made a stupid solution design or if microsoft was kind of ignoring those enterprise systems in their ecosystem.
Hi Alan. I can’s say much about the design, but I can certainly recall at east a couple of situations from my own experience when trying to do all calculations in the plugin would make on-premise Dynamics server almost non-responsive. I think Microsoft had to balance this kind of scenarios somehow in the online version/CDS, so the move towards API limits does not surprise me that much. If anything, I think this is not, yet, even final, since it might be much more fair to measure consumption in some kind of resource units. Otherwise, a single record read would be priced similar to a 100 different reads batched together through the same API call. Anyway, what used to help me in those situations is offloading all calculations into a separate SQL database. In theory, we can use Azure SQL database to try implementing the same approach with CDS, but whether it’s going to be cost-effective is yet another question.
Looks like the rules might have changed since this post was made.
“Batch operations are not a valid strategy to bypass entitlement limits. Service protection API limits and Entitlement limits are evaluated separately. Entitlement limits are based on CRUD operations and accrue whether or not they are included in a batch operation. More information: Entitlement limits”
https://docs.microsoft.com/en-us/powerapps/developer/data-platform/api-limits
You are correct. Everything is counted now, though I’m pretty sure the original idea was a little different. Anyways, keeping old post as is:)