API limit for Microsoft Dataverse
Microsoft writes that the Microsoft Dataverse API limit helps ensure service levels, availability, and quality. This is regarding best practice architecture on using external APIs and good programming design…. Let me explain. (updated 08/12-2023 with latest info)
The first thing to acknowledge is that two limitations serve two purposes. Microsoft refers to them as “Licensed user request” vs “Non-licensed user request limits”.
Licensed user request limits are not enforced yet, read here: Microsofts statement , where Non-licensed user request limits have been enforced since 2018’ish. Any possible high usage enforcement won’t happen until six months after Power Platform Request usage reporting has been generally available in the Power Platform Admin Center. There usage reports are currently in public preview: Requests limits detailed Power Platform, find them here in Power Platform Admin center: Power Platform admin center/resource/Download
Licensed user request limits
The Licensed user request limits are there to help me focus on good programming design and skills, let me explain.
Rules
The count towards the “API limit” is 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 initiates the CRUD ( plug-ins, async workflows, custom controls, custom apps and $batch (ExecuteMultiple) operations etc.) it will count towards this limit. Types of Power Automate licenses – What counts as Power Platform request?
Different licenses give different user request limits:
| User licenses | CRUD Entitlement / 24 hours |
|---|---|
| Paid licensed users for Power Platform and Dynamics 365 (excludes Power Apps per App, Power Automate per flow, and Power Virtual Agents, and Dynamics 365 Team member) | 40,000 per user |
| Dynamics 365 Team Member | 6,000 per user |
| Power Apps pay-as-you-go plan | 6,000 per user |
| Microsoft 365 apps with Power Platform access | 6,000 per user |
| Power Apps per app | 6,000 per user |
| Power Automate per flow plan / Power Automate Process, Power Virtual Agents base offer, and Power Virtual Agents add-on pack | 250,000 |
| Power Portals & Power Pages | 200 per user |
Consequence
“If the user exceeds their request entitlement, the administrator would be notified and 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 compliant.
If a user has multiple paid licenses assigned to them, the total number of requests allowed would be the sum of requests allowed for each license. For example, if a user has both a Dynamics 365 Customer Service Enterprise base license and a Power Apps per user license, then that user will have a total of 40,000 + 40,000 = 80,000 requests available per 24 hours.
Microsoft plays nice and communicates with the admin without taking the end-users as hostages. Microsoft reserves the right to enforce limits for overage. Customers who encounter high usage enforcement can expect some form of throttling. Customers can purchase additional capacity to avoid high usage enforcement or move their environment to pay-as-you-go and pay for actual usage above daily limits.
Focus on good programming design and skills
Be proactive and do a code review of custom build plugins for them to do as few CRUD operations as possible.
Doing code review and limiting read and write operations will help stay below the 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 lists the 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
Non-licensed user request 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 using Dataverse APIs.
This limit is related mostly to “Service accounts,” which in Dataverse are these four types:
Rules
Microsoft writes:
“Request limits 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 & Professional applications1 | 500,000 base requests + 5,000 requests accrued per USL1 up to 10,000,000 max2 |
| Microsoft Power Apps or Power Automate (all licenses) | 25,000 base requests with no per-license accrual for the tenant |
2If you anticipate exceeding the non-licensed user limits, reach out to your reseller or Microsoft Account team to discuss a custom solution.
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 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 number of web servers available to your environment depends on multiple factors that are part of the managed service Microsoft provides. One of the factors is how many users licenses you have purchased.”
The following table describes the default service protection API limits enforced per web server:
| Measure | Description | Limit per web server |
|---|---|---|
| Number of requests | The cumulative number of requests made by the user. | 6000 within the 5-minute sliding window |
| Execution time | The combined execution time of all requests made by the user. | 20 minutes (1200 seconds) within the 5-minute sliding window |
| Number of concurrent requests | The number of concurrent requests made by the user | 52 or higher |
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 your design.
Move away from batch import and move closer to an event-driven trigger data import.
Set up 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 blog post. As always, Customers are responsible for following license-guide and the latest documentation, so please read these and only use blog posts as references to what to read in official documentation or license guides.
API limits overview (Microsoft Dataverse) – Power Apps | Microsoft Docs
Service protection API limits (Microsoft Dataverse) – Power Apps | Microsoft Docs
Requests limits and allocations – Power Platform | Microsoft Docs
Power Apps and Power Automate Licensing Guide.
Community Paranoia
Historically the documentation and communication from Microsoft on these API limits have been and still caused some “paranoia.” In the last year or so, people have learned the reality of the impacts of these limits, or better said, the 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 blogposts that have different angles and perspectives; where most of which are from 2018-19. The reason is most ambiguities were 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
Please comment below if you still have API Limit Paranoia after reading this blog post, I might have missed something important.
One thought on “Excuse me! API limits for Microsoft Power Platform Dataverse & Dynamics 365 (2023 Edition)”