The short version: Two different ceilings apply to Dataverse API calls, as at 22 September 2026: a per-licence entitlement of 6,000 to 250,000 requests every 24 hours, and a separate service protection limit of 6,000 requests, 1,200 seconds of execution time or 52 concurrent requests within any five-minute window, whichever a caller hits first. A firm under 20 staff almost never reaches either through normal use; a badly designed integration can hit the second one in minutes.
The two ceilings, side by side
| Limit type | Figure | Window |
|---|---|---|
| Standard user licence | 40,000 requests | 24 hours |
| Per-app or Microsoft 365 licence | 6,000 requests | 24 hours |
| Power Automate per-flow or Process | 250,000 requests | 24 hours |
| Service protection, number of requests | 6,000 requests | 5-minute sliding window, per web server |
| Service protection, execution time | 1,200 seconds (20 min) | Same 5-minute window |
| Service protection, concurrency | 52 requests at once | Evaluated continuously |
These aren't the same thing measured two ways. The 24-hour figure is an entitlement tied to what a licence pays for; it is enforced softly today, with the tenant admin notified before anyone is blocked. The five-minute figures are service protection limits, enforced immediately with a hard error, and they exist purely to stop one runaway process from degrading Dataverse for every other tenant sharing the same web server.
What it means for a firm under 20 staff
A small team clicking through a canvas app or running a handful of flows a day is nowhere near either limit; a Power Apps per-app user's 6,000-request daily allowance already covers thousands of ordinary form saves and lookups. The service protection limit that actually bites is 6,000 requests in five minutes, and the way a small firm hits it is almost always a bulk operation: a nightly data migration script, a Power Automate flow looping over ten thousand rows one record at a time, or a report tool re-querying Dataverse on every refresh instead of caching. Each is an ordinary one-off cleanup job, the kind that runs fine in testing on fifty rows and falls over in production on fifty thousand.
The 24-hour entitlement matters more when licences are mixed: a user with both a Power Apps per-user plan and a Dynamics 365 plan gets the sum of both allowances, so stacking the right licence against a heavy user is often cheaper than buying a dedicated capacity add-on.
The workaround
For the five-minute wall, the fix is architectural, not a bigger number to ask Microsoft for: batch operations into fewer, larger requests using ExecuteMultiple or the Web API's $batch, spread heavy work across more than one flow or user so it isn't tracked against a single account, and let the server tell you the pace by respecting the Retry-After header instead of guessing a safe rate. For the daily entitlement, a Power Platform Request capacity add-on adds another 50,000 requests a day to a specific high-usage user, and multiple add-ons can be stacked, but for a firm under 20 staff a licence swap usually solves it more cheaply than an add-on. Which licence gives which allowance in the first place is exactly what the licence picker is for.
Common questions
How many API requests does each Power Platform licence allow per day?
It depends on the licence: 40,000 a day for a standard Power Apps or Power Automate per-user plan, 6,000 for a Power Apps per-app plan or a Microsoft 365 licence with Power Platform access, and 250,000 for a Power Automate per-flow or Process plan. These are entitlement limits, evaluated over 24 hours.
What is the Dataverse service protection limit, and how is it different from the daily entitlement?
Service protection limits guard the platform itself, not a licence: 6,000 requests, 1,200 seconds of combined execution time, and 52 concurrent requests, each within a rolling five-minute window, per web server, per user. They apply on top of the daily entitlement and exist to stop one heavy integration slowing the service for everyone else.
What happens when a user or app exceeds the request limit?
A service protection breach returns an immediate 429 Too Many Requests error with a Retry-After value telling the caller how long to wait. An entitlement breach is softer: the admin gets notified and can assign extra capacity to that user, and the app keeps running rather than being blocked outright, at least for now.
Seeing 429 errors from Dataverse?
Free 30-minute call. Tell me what the flow or integration does and I'll tell you whether it's a licence problem or a design problem.