Every article about Power Platform request limits quotes the same number. 40,000 requests per paid user per 24 hours. It's in the docs, it's real, and it is almost certainly not the thing throttling your flows.
There are three separate limit systems running at once, they have different numbers and different scopes, and only one of them is currently being enforced. Most of the confusion in this space comes from articles that quote the first set and stop.
The daily entitlements are not being enforced
Start here, because it changes how you read everything else.
The daily allocations are documented. They're also not enforced today. High usage enforcement doesn't begin until at least six months after Power Platform Requests reporting reaches general availability in the admin centre, and those reports are still in preview with no announced GA date. Every organisation is still in what Microsoft calls the transition period.
So if you're getting throttled, it isn't because you exceeded 40,000 requests in a day. Something else stopped you.
For when it does start mattering, the allocations are worth knowing. A paid user licence carries 40,000 requests per 24 hours. The 6,000 tier covers Power Apps pay as you go, Power Apps per app, Microsoft 365 apps with Power Platform access, and Dynamics 365 Team Member.
Here's a detail I see wrong constantly. People say seeded licences get 6,000. Most don't. Seeded Power Apps Premium gets 40,000. Seeded Dynamics 365 Professional gets 40,000. Seeded Dynamics 365 Enterprise gets 40,000. It's Microsoft 365 and Team Member that sit at 6,000. If you've been budgeting your integration capacity on the assumption that everything seeded is a 6,000 licence, you've been pessimistic by a factor of nearly seven.
The limits that actually stop you
Service protection limits are the ones doing the throttling, and they work on a completely different clock.
Three limits, measured per user, per web server:
- 6,000 requests within a 300 second sliding window
- 1,200 seconds of combined execution time within a 300 second sliding window
- 52 concurrent requests
The phrase to pay attention to is per web server. Most environments run more than one. This is why your burst headers seem to reset unpredictably, why the same load succeeds on one run and fails on the next, and why Microsoft tells you not to build logic against those headers. You're not talking to one counter, you're talking to whichever server picked up your request.
One useful exemption: traffic from plug-ins and custom workflow activities is out of scope for service protection. Code running inside the platform isn't spending your service protection budget.
And then the transition period limits
There's a third set, and they're scoped differently again. Not per user. Per flow.
During the transition period, a cloud flow on Power Automate Premium gets 200,000 actions per day. A Process licence gets 500,000, and up to ten Process licences can stack on one cloud flow, each adding 250,000 actions per day to the official entitlement. There's also a separate ceiling of 1,000,000 cloud flow actions per user per day.
All of that is transition period only. When it ends, limits revert to per user for Premium and per cloud flow for Process and per flow licences. So the number you plan against today is not the number you'll be measured on later, and the scope changes too, not just the value.
Reading a 429
When something throttles, the error tells you which system caught you if you know what to look for.
OperationRequestThrottled and the signed decimal codes -2147015902, -2147015903 and -2147015898 are service protection. So is anything that mentions a window, like the string about a number of requests exceeding some count per some duration. Those point at the five minute limits, not the daily ones.
If you're seeing a limit that isn't in the documented set at all, you're not imagining it. People have hit undocumented per hour operation limits on APIs that worked fine for a year, with no customer announcement anywhere. That happens.
What this means practically
Stop sizing integrations against the daily number. It isn't enforced yet and when it is, you get at least six months of warning after the reporting goes GA.
Size against service protection instead, because that's live today. The constraint that bites real integrations is usually the 1,200 seconds of execution time in five minutes rather than the 6,000 request count, especially if you're doing anything with large payloads or expensive plug-ins in the pipeline.
Build retry with exponential backoff and honour the Retry-After header. Don't build against the burst remaining headers, because of the per web server thing.
And if you're trying to work out whether your licence mix covers what your flows already do, our request limit calculator will do it, and it separates the enforced limits from the documented ones rather than lumping them together.