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.


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 licensesCRUD 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 Member6,000 per user
Power Apps pay-as-you-go plan6,000 per user
Microsoft 365 apps with Power Platform access6,000 per user
Power Apps per app6,000 per user
Power Automate per flow plan250,000
Power Portals & Power Pages200 per user


“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”.


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:


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.”

SubscriptionRequest per 24 hours
Dynamics 365 Enterprise & Professional applications1500,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
1 This category includes licenses for Dynamics 365 Sales Premium, Dynamics 365 Sales Enterprise, Dynamics 365 Sales Professional, Dynamics 365 Customer Service Enterprise, Dynamics 365 Customer Service Professional, Dynamics 365 Field Service, Microsoft Relationship Sales, Dynamics 365 Project Service Automation, Dynamics 365 Commerce, Dynamics 365 Human Resources, Dynamics 365 Finance, Dynamics 365 Project Operations, Dynamics 365 Supply Chain Management, Dynamics 365 Customer Engagement plan, Dynamics 365 Unified Ops plan, Dynamics 365 Plan, Dynamics CRM Online Enterprise, and Dynamics CRM Online Professional. Power Platform Request accrued non-licensed tenant-level limits are only granted with paid base licenses in the Dynamics 365 ‘base + attach’ licensing model.
2If you anticipate exceeding the non-licensed user limits, reach out to your reseller or Microsoft Account team to discuss a custom solution.


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:

MeasureDescriptionLimit per web server
Number of requestsThe cumulative number of requests made by the user.6000 within the 5-minute sliding window
Execution timeThe combined execution time of all requests made by the user.20 minutes (1200 seconds) within the 5-minute sliding window
Number of concurrent requestsThe number of concurrent requests made by the user52

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:




Please comment below if you still have API Limit Paranoia after reading this blog post, I might have missed something important.

8 thoughts on “Excuse me! API limits for Microsoft Power Platform Dataverse

    1. 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

      1. 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?

  1. Enforcement of limitations should be coming up soon.
    There are some ways to make your flows much more efficient in api calls, which may be more elegant than spreading one’s workflows across several accounts and/or set-ups.

    If anyone runs into call limits, throttling, or other performance issues when creating, updating, or deleting many items in SharePoint, Excel, or SQL, then you may find these 50-1000x more efficient batch templates useful…

    Update, Create, & Upsert- https://powerusers.microsoft.com/t5/Power-Automate-Cookbook/Batch-Update-Create-and-Upsert-SharePoint-Lists/td-p/1365410
    Create- https://www.tachytelic.net/2021/06/power-automate-flow-batch-create-sharepoint-list-items/?amp
    Delete- https://www.tachytelic.net/2021/06/power-automate-delete-sharepoint-items/

    Create & Update- https://powerusers.microsoft.com/t5/Power-Automate-Cookbook/Excel-Batch-Create-Update-and-Upsert/td-p/1624706
    Delete- https://powerusers.microsoft.com/t5/Power-Automate-Cookbook/Excel-Batch-Delete/td-p/1634375

    Use stored procedures:
    Or this batch template:

    Also in many cases you can use two Filter arrays, one for true/yes, one for false/no instead of conditionals within an Apply to each.

    Finally, make sure you are using trigger conditions for flows that only need to run in a sub-set of cases in which an action is performed

Leave a Reply