Microsoft writes that the Microsoft Dataverse (Common Data Service) API limit help ensure service levels, availability, and quality. For me this is regarding best practice architecture on how to use external APIs and good programming designâŚ. let me explain.
The first thing to acknowledge is that there are two different limitations that serve two different purposes. Microsoft refers to them as âEntitlement limitsâ and âService protection limitsâ.
Entitlement limits are not enforced yet, read here: Microsofts statement on when limits will “go live” how and when. Where service protection limits have been enforced since 2018âish.
đEntitlement limits
The entitlement limits are there to help me focus on good programming design and skills.
The documentation says that Entitlement limits are counted towards the number of requests users are making each day. So, in plain English the limit relates to user of the application. (see Assumptions in bottom of blog post)
Rules
The count towards the âAPI limitâ are defined by Microsoft as all ârequests include all data operations that interact with table rows where rows are created, retrieved, updated, or deleted (CRUD)â. No matter how the user initiated the CRUD ( plug-ins, async workflows, custom controls, custom apps and $batch (ExecuteMultiple) operations etc.) it will count towards this limit.
Different licenses give different entitlement:
| User licenses | CRUD Entitlement / 24 hours |
|---|---|
| Dynamics 365 Enterprise applications | 20,000 |
| Dynamics 365 Professional | 10,000 |
| Dynamics 365 Team Member | 5,000 |
| Power Apps per user plan | 5,000 |
| Power Apps per app plan | 1,000 per user pass |
| Power Automate per user plan (+ RPA) | 5,000 |
| Portals | 200 per user |
| Portals Anonymous page views | 3 per page view |
API limits for Power Apps portals are a bit special as they are pooled at portal level depending on number of logins/page views assigned to portal.
Consequence
âIf user exceeds their request entitlement the administrator would be notified and would be able to assign Power Apps and Power Automate request capacity to that user.
While occasional and reasonable overages will be tolerated, customers exceeding licensed capacity should adjust their purchase quantity per standard Microsoft terms to remain in compliance.
Microsoft plays nice and communicates with the Admin without taking the end users as hostages.
Focus on good programming design and skills
Be proactive and do code review of custom build plugins for them do as few CRUD operations as possible..
Do code review and limiting read and write operations will help stay below limit. (Limit equates to opening ~2 records a minute assuming that the user is opening records constantly for 8 hours straight http://develop1.net/public/post/2019/09/04/how-do-the-powerplatform-api-limits-affect-model-driven-apps)
Do not use normal user accounts for automated data integration, use non interactive users.
If the above fails, please monitor the administrator notification in office 365 notification center for these events and react to either limit CRUD-operations or procure a larger entitlement per user to stay compliant.
Do you want to get insight on how close you are to these limits then look at the Power Platform Analytics report that list most active users (unique users) over time, who performed an operation that caused one of these SDK calls: Retrieve, Retrieve Multiple, Delete, Create, and Update. Filter downloaded Excel to remove ânon interactive usersâ to only view ânormal usersâ.
https://docs.microsoft.com/en-us/power-platform/admin/analytics-common-data-service#download-reports
đService protection API limits
Microsoft writes that this limit is set in place âTo ensure consistent availability and performance for everyoneâ and that âThe limits will not affect normal users of the platformâ. As I understand it, the Service protection limits are there to help me focus on best practice architecture on how to use Common Data service APIs.
This limit related mostly to âService accountsâ which in Common Data Service are there four types:
Rules
Microsoft writes:
âRequest limit are evaluated within a five-minute sliding windowâ
âService protection limits apply to all external web service requestsâ
âService protection API limits are not applied against API calls made within workflows, custom workflow activities, or plug-in code. These operations are invoked internally.â
| Subscription | Request per 24 hours |
|---|---|
| Dynamics 365 Enterprise | 100,000 |
| Dynamics 365 Professional | 50,000 |
| Microsoft Power Apps or Power Automate | 25,000 |
Consequence
Microsoft writes: âWhen this limit is exceeded, an exception will be thrown by the platform.â for code using the application user to handle in a retry setup & âif a user or flow exceeds the limits consistently for an extended period (more than 14 days), that non-interactive user may be disabled, or flow turned off.â
For most large enterprise businesses this will be hard to estimate up front as Microsoft writes: âEach web server available to your environment will enforce these limits independently. Most environments will have more than one web server. The actual number of web servers that are available to your environment depends on multiple factors that are part of the managed service Microsoft provide. One of the factors is how many user licenses you have purchased.â
Read how to handle this you your integration code including details of behavior here: https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/api-limits
Best practice architecture on how to use external APIs.
Use non interactive users for integration.
Read more about Data Integration architecture for Microsoft Common Data Service, Dynamics 365, and PowerApps
Do not expect the APIs to be up and running, therefore build fault tolerances into you design.
Move away from batch import and move closer to an event driven trigger data import.
Setup some monitoring on this âexceptionâ for you to know when this limit is reached and affection integrations etc.
Source of information
There are more details to this topic that I write, but it-is adding details, it does not change the overall information given in this blogpost. As always, Customers are responsible to follow license-guide and latest documentation, so please read these and only use blog post as references to what to read in official documentation or license guides.
https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/api-limits-overview
https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/api-limits
https://docs.microsoft.com/en-us/power-platform/admin/api-request-limits-allocations
Power Apps and Power Automate Licensing Guide.
Community Paranoia
Historical the documentation and communication from Microsoft on these API limits have been and still caused some âparanoiaâ. The last year or so people have learned the reality of impacts of these limits, or better said, lack of negative impact so blog posting on this topic has quieted down.
On top of this documentation has become better but not perfect. You will find some of the community blogpost that have different angles and perspective, where most of them are from 2018-19. The reason is most ambiguity was found in communication and documentation from Microsoft in these years. Find most of them doing this search: https://www.google.com/search?q=dynamics+365+api+limits
ISV Partners on the topic:
https://support.tibco.com/s/article/Microsoft-D365-CRM-CE-request-limits-allocations-and-API-Limits
http://www.kingswaysoft.com/blog/2018/02/27/How-to-Cope-with-the-new-Dynamics-365-API-Limits
https://support.clickdimensions.com/hc/en-us/articles/360034489751-Microsoft-API-Limit-Changes
Assumptions taken in this blog post
It is unclear in the documentation as of 14. Nov. 2020 what the term âusersâ cover in text regarding âentitlement limitsâ. I assume that it is toward entitlement limit as entitlement limits is for âend users/interactive usersâ of the product and not for Application users etc. (non-interactive users) as non-interactive users are covered by âService protection limitsâ.
I have requested documentation clarification, follow progress here: https://github.com/MicrosoftDocs/powerapps-docs/issues/1930#issue-743107189
It is unclear if it is possible to extend âService protection limitsâ. I have requested documentation clarification Follow progress here: https://github.com/MicrosoftDocs/power-platform/issues/472
Please write a comment below if you still have API Limit Paranoia after reading this blog post, I might have missed something important.
What are the API limits for integration users?
Service protection limit related mostly to âService accounts/integration usersâ which in Common Data Service are there four types:
Application users
Non-interactive users
Administrative users
SYSTEM user
Maybe this is a stupid question, but does that mean that an integration user is limited to 100.000 API calls per 24 hour, no matter how many users you have? How will you then do an initial load of example 2 million records?
To work around Service protection limit one could use the ExecuteMultipleRequest to have more data imported in one API call https://docs.microsoft.com/en-us/dotnet/api/microsoft.xrm.sdk.messages.executemultiplerequest?view=dynamics-general-ce-9 Read
more on optimising throughput here: https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/api-limits#how-to-maximize-throughput