API request limits

What it does

Power Platform requests are the daily budget of actions a user or a licensed flow can execute. Every trigger and every action counts — connector calls, HTTP actions and built-in actions alike — measured over a sliding 24-hour window against whichever licence context the flow runs in.

Key facts

Official 24-hour limits: 40,000 per user for Power Automate Premium, Power Apps Premium, Dynamics 365 Professional and Enterprise; 6,000 per user for Free, Microsoft 365 and Dynamics 365 Team Member; 250,000 per licence for Process, Hosted Process and the legacy Per-flow plan.
Every organisation is currently in a transition period with more generous limits applied at the cloud flow level rather than the user level — 200,000 per flow where the official limit is 40,000 per user, 500,000 per licence where it's 250,000, 10,000 per flow where it's 6,000. A separate 1,000,000-action per-user-per-day ceiling also applies during the transition.
A five-minute limit of 100,000 requests applies regardless of licence.
Both successful and failed actions count. Skipped actions don't. Retries and pagination requests count. A loop counts as one action plus its contents once per iteration.
Automated and scheduled flows use the owner's limits. Instant flows use the invoking user's. A Process or Per-flow licence overrides everything and uses its own limit. A service principal owner draws on the non-licensed user pool.
Non-licensed identities — application, non-interactive, administrative and SYSTEM users — share a pooled tenant limit: 25,000 base requests for Power Automate, or 500,000 base plus 5,000 accrued per Dynamics 365 Enterprise or Professional user licence, capped at 10,000,000.
Requests don't roll over, day to day or month to month.
Desktop flow executions don't consume Power Platform requests.
Capacity is tracked per user or per flow and can't be pooled at environment or tenant level.
The Power Platform Request capacity add-on adds 50,000 requests per 24 hours per unit, but can't be assigned to users or flows during the transition period.

When to use / skip

This isn't something you opt into — it's a design constraint. Where it matters is in high-volume patterns: a flow that iterates over thousands of rows, a trigger that fires on every email to filter for one sender, or anything with nested loops. Design those to minimise action count before you buy capacity, because a well-shaped flow often uses an order of magnitude fewer actions than the obvious one. Buy Process capacity or move to pay-as-you-go when the volume is genuinely necessary rather than accidental.

Configuration decisions

Whether a high-volume flow is licensed on the owner's user entitlement or moved onto a Process licence with its own allowance.
Whether Process licences are stacked, and how many, based on measured actions per run multiplied by runs per day.
Whether the environment moves to pay-as-you-go, which Microsoft points to as the way to avoid throttling entirely.
Whether background work runs under a service principal, which changes the applicable pool from a user entitlement to the tenant non-licensed pool.
Whether flow design changes — filtering at the trigger, batching, fewer compose actions — are cheaper than more capacity.

Gotchas

Enforcement status is the thing to be careful about. Microsoft reserves the right to enforce, but says high usage enforcement won't begin until at least six months after the admin centre request reports reach general availability, and there's no published ETA for that. Meanwhile Power Automate still throttles at the transition limits.
Because transition limits apply per flow rather than per user, an estate that looks comfortable today can breach the official per-user limits the day the transition ends. Build to the official numbers.
Manual flows currently get a Medium performance profile of 100,000 requests per flow per day. After the transition they'll use the invoking user's limits instead, which is a meaningful downgrade for widely-shared instant flows.
Licence stacking isn't supported during the transition. A user with both Microsoft 365 and Dynamics 365 gets the higher plan, not the sum — though outside the transition, multiple paid licences do sum.
The admin centre reports are in preview and cover Power Automate requests only. Dataverse, Power Apps and Copilot Studio requests aren't included.
The licensed user preview report shows 0 entitlement for Power Apps per app users when it should show 6,000.
Non-Microsoft integration tools are subject to the same limits. Swapping Power Automate for another tool doesn't avoid them.

Consultant notes

Design to the official limits, not the transition limits. Anything else is building a problem into the client's estate with a delivery date you can't predict.
Get the client's admin to pull the Power Platform requests report early and use real numbers. Estimating action counts by eye is unreliable, particularly where loops are involved.
The "one trigger, one action equals two actions" arithmetic is worth walking a client through once. It reframes how they think about a flow that runs every minute.
Where throttling is already happening, Microsoft's documented route is pay-as-you-go, or buying add-ons or a Process licence and raising a support ticket for an exception. Say that plainly rather than promising a config fix.

Worth revisiting when the admin centre request reports reach general availability, since that starts the clock on the transition period ending.