How do the PowerPlatform API Limits affect Model Driven Apps?

You might have seen the important announcement from the PowerPlatform team about how there are new API limits to be in effect from the 1st October 2019.

We have been somewhat spoilt in past years with very little throttling on how much we can use the API, but now in order to encourage fair usage there will be a limit on how many times you can call the PowerPlatform API in a 24hr period, depending on the license you have:

User licenses Number of API requests / 24 hours
Dynamics 365 Enterprise applications 20,000
Dynamics 365 Professional 10,000
Dynamics 365 Team Member 5,000
PowerApps per user plan  5,000 
Microsoft Flow per user plan  5,000 
Office licenses (that include PowerApps/Microsoft Flow)  2,000 

(taken from

There is a section in the article that calls out what a PowerPlatform Request is and it seems to be quite clear that it's any Connector calls, Flow Step Actions, and CDS API CRUD type calls.

How does this affect Model-Driven Apps and WebApi calls?

One of many improvements of the Unified interface over the legacy Web UI is that it is much less 'chatty' to the server - but there are still ~10 calls for a simple contact form load once metadata has been loaded and cached.

If I filter the network requests to '/api/data/v9' when opening a Unified Client Contact form with no customisations, I get 17 requests:

On examination of these requests, there are some requests that will not count as an API Call:

  • 304 Not modified requests - where data is cached (4)
  • Calls to 'special' actions such as  'GetClientMetadata' which will not count as an API call (2)
  • Calls to UpdateRecentItems (1)

This leaves 10 calls to the Web API endpoint, all of which will count towards the API limit. It's worth noting that the $batch calls only count as a single API Call even though they can contain multiple requests.

What does this mean in 'Real Terms'?

Let's assume the following:

  • A user has a Dynamics 365 Professional license giving them 10,000 API calls/day
  • There are no Flows, CanvasApps, Workflows, Plugins that are running under their user identity
  • There are no customisations made to the standard 'Sales Hub' contact form.
  • There are no other ISV products installed

Assuming this, the user would be able to open approximately ~1000 contact records before they hit the API limit.

This equates to opening ~2 records a minute assuming that the user is opening records constantly for 8 hours straight! 🤣

The good news is that Users will not be blocked if they exceed the limit, the environment administrator will be notified so that they can take action and perhaps purchase an API Limit add-on (details of which are yet to be published but I'll update this post when they are).

Custom vs First Party

The key takeaway here is that the new limits do not differentiate between custom calls to the WebApi made by the out of the box code and custom code. 

Any calls your custom JavaScript makes to Xrm.WebApi.* from inside your Model-Drive Apps will count as an API call alongside the 10 calls we see above.

Call to action!

What does this mean for Model Driven App developers? Well, it's fairly clear that the new API limits are not overly generous, but shouldn't pose too much of an issue for normal users as long as you ensure that you minimize the custom API calls that you make from inside your Model-Driven code. The good news is that the JavaScript Xrm.WebApi already implements etag cache support for you - you can read my blog post about how it'll help you keep your API calls down!

Note: I will update this post if I hear of any changes that come down the line from this announcement. 

Comments (14) -

  • Hi Scott, how would you recommend a prospective customer estimates their API usage when evaluating Dynamics 365 so that they can estimating their total subscription costs? It's pretty challenging for my customers to estimate how much they'll consume of something they haven't built yet, so any creative ideas you've got would be very handy!
    • I think it's going to be the same as estimating storage costs or Azure consumption costs - lots of Excel!
      • Scott and Neil,

        This is a topic that is going to cause hesitancy in purchasing. What are the costs for exceeding this number? Is this a collective number, as in if you have 1000 users you get 1000 x API Stipend to be used collectively?

        Thanks Scott for covering this topic.

  • The price lists I have seen suggest the 10k API call add-on packs will cost approx $50USD.

    Appreciate the info that it will not be enforced as a hard limit, can you confirm if there is anywhere official stating as such? I haven't seen any official Microsoft documentation to that effect, and I feel this is important to get so we can go to our customers with some certainty of how they can plan for this change. If it isn't enforced as as hard limit (I assumed it would work the same way as the 5 minute request window) this would go a long way towards alleviating concerns, similar if they gave some information about grace period, which as far as I have seen also appears lacking.
  • What if we are doing a bulk CRUD operation?
  • Thanks for this wonderful article Scott
  • Hi Scott

    Thanks for the details. A qq though, if from inside plugin I'm doing service.retrive/update etc, does it count as separate requests? How about those SSIS CRUDs .. if I'm dumping a million records via SSIS?
    • Plugin Calls will count as API Calls as I understand it -
      SSIS CRUD calls also will be counted and so you'll need to make as much use of batch operations and caching as you can!
      • Hi Scott,
        Are plug-ins, async workflows & custom controls calls are counted?
        It's mentioned here as, "Since plug-ins and custom workflow activities execute on the server independent of a logged on user, API calls made from plug-in code will not count against this external API request limit."

        So confusing! Frown
        • Yes - plugins, workflow and custom control calls are counted towards the limit provided they are running under a user identity.
        • Hi! That is the service protection limits - rather than the API limit. Any CRUD calls count towards the API limit no matter where they come from.
  • The API add-on is mentioned in one of the documents - its $50 for 10,000 api calls a day and being honest I've never been that concerned with the API limits for users as they will have been extensively validated before the limits were set. What annoyed me was that various Fast Track Engineers were as surprised as everyone else when this announcement was made.

    What it does mean is that for people using the single app / month $10 licences it will be far cheaper to create additional user accounts instead of using the licence, and I'm currently rewriting a lot of code to use a lot more caching.
    • Ben,

      Do you see problems with caching data? What about organizations that rely on accurate customer transactions within a day? Maybe I am misunderstanding how you are caching or what you are caching but it would seem to me two problems might exist. One, retrieving more information than required per API call in order to round out the cache. Two, the cache will lead to stale data if used for an entire day in some multi-user highly collaborative environments such as field service.
  • And how would it affect the service accounts that we use for data migration ?
Comments are closed