Excuse me! API limits for Microsoft Power Platform Dataverse

API limit for Microsoft Dataverse

Microsoft writes that the Microsoft Dataverse 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. ( updated 27/8-2022 with latest info )

The first thing to acknowledge is that two different limitations serve two different 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.

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	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 in compliance.

Microsoft plays nice and communicates with the admin without taking the end-users as hostages. Microsoft reserves the right to enforce limits for overages. If a customer encounters high usage enforcement, they 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:

• Application users
• Non-interactive users
• Administrative users
• SYSTEM user

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

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

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.