Connector Throttling & API Limits Reference

Why Throttling Matters

Every Power Platform connector has rate limits. Hit them and your flows fail with 429 errors, your apps show mysterious “network error” messages, and your users lose trust in the solution. Understanding these limits upfront saves hours of debugging later.

This reference covers the most commonly encountered throttling limits, per-user request entitlements, and practical strategies for staying within bounds.

Connector-Specific Throttling Limits

These are the per-connection limits enforced by each connector. They apply regardless of your licence tier.

Microsoft 365 Connectors

Connector	Limit	Period	Notes
SharePoint	600 requests	Per minute, per connection	Applies to both REST API and connector actions
SharePoint	12,000 requests	Per day, per user	Combined across all connections for that user
Outlook (Office 365)	10,000 requests	Per day, per mailbox	Includes send, read, move, delete actions
Outlook (Office 365)	30 requests	Per minute, per mailbox	Sending emails specifically
Excel Online	300 requests	Per minute, per connection	Higher for read-only operations
OneDrive for Business	600 requests	Per minute, per connection	Upload/download combined
Microsoft Teams	60 requests	Per minute, per app per user	Posting messages, creating channels
Microsoft Teams	3 requests	Per second, per channel	Channel message posting
Planner	300 requests	Per minute, per app	Task creation and updates
Microsoft Forms	200 requests	Per minute, per user	Reading responses

Dataverse

Limit Type	Limit	Period	Notes
API requests	6,000	Per 5 minutes, per user	Aggregate across all operations
Concurrent requests	52	Per user	Simultaneous open requests
ExecuteMultiple	16	Concurrent batch requests	Per org, per user
Batch size	1,000	Requests per batch	ExecuteMultiple batch limit
Retrieve multiple	5,000	Records per page	Use paging cookie for more

SQL Server / Azure SQL

Limit Type	Limit	Notes
Concurrent connections	100	Per connection string
Requests	600	Per minute, per connection
Timeout	110 seconds	Per operation
Row limit	2,048	Per query result (paging required for more)

HTTP Connector (Premium)

Limit Type	Limit	Notes
Requests	500	Per minute, per flow
Payload size	104 MB	Request body limit
Timeout	120 seconds	Per request (230 seconds in async mode)
Response size	104 MB	Response body limit

Other Common Connectors

Connector	Limit	Period	Notes
Azure Blob Storage	600	Per minute	Read/write combined
Approvals	300	Per minute, per environment	Create + respond combined
Dataverse (legacy CDS)	6,000	Per 5 minutes, per user	Same as Dataverse
Power BI	200	Per hour, per user	Dataset refresh and API
Adobe PDF Services	500	Per day, per environment	PDF creation and manipulation
Key Vault	600	Per minute	Secret read/write
AI Builder	Varies	Per AI credit allocation	Depends on model type

Power Platform Request Entitlements by Licence

Beyond connector-specific limits, Microsoft enforces a per-user daily request limit across the entire Power Platform. These are “Power Platform requests” and include connector actions, flow runs, and Dataverse API calls.

Request Limits Per 24-Hour Period

Licence	Daily Request Limit	Notes
Microsoft 365 E1/E3/E5	6,000	Included, no extra cost
Power Apps per-user	40,000	Per licensed user
Power Automate per-user	40,000	Per licensed user
Power Apps per-app	6,000	Per app pass, per user
Power Automate per-flow	250,000	Shared across the flow (not per user)
Dynamics 365 Enterprise	40,000	Per licensed user
Dynamics 365 Professional	40,000	Per licensed user
Dynamics 365 Team Member	6,000	Per licensed user
Power Platform request add-on	50,000	Per unit purchased, stackable

What Counts as a Request

Each of the following counts as one Power Platform request:

A connector action execution in a flow (each action in a flow run is one request)
A Power Apps data call (Patch, Collect, LookUp against a data source)
A Dataverse API call (CRUD operations)
A flow trigger check (polling triggers that check for new data)

What Does Not Count

Client-side Power Apps operations (local variables, collections from cached data)
Power BI report views (but dataset refreshes do count)
Static page loads of model-driven or canvas apps

Understanding 429 Errors

When you exceed a limit, the connector returns HTTP 429 (Too Many Requests). The response includes a Retry-After header telling you how many seconds to wait.

How Power Automate Handles 429s

By default, Power Automate automatically retries 429 responses with exponential backoff:

First retry after the Retry-After period (or 20 seconds if not specified)
Second retry after double the wait
Up to 4 retries by default
After all retries fail, the action fails with “TooManyRequests”

Configuring Retry Policy

You can customise the retry behaviour on any action via Settings > Retry Policy:

Policy	Behaviour
Default	4 retries, exponential backoff
Exponential Interval	Configurable count, min/max interval
Fixed Interval	Configurable count and fixed wait time
None	No retries — fail immediately

For high-volume flows, set a longer minimum interval and increase the retry count:

Count: 8
Minimum Interval: PT30S (30 seconds)
Maximum Interval: PT5M (5 minutes)

Connector-Specific Gotchas

SharePoint: The Hidden 12,000 Daily Limit

Most people know about the 600/minute limit, but the 12,000 requests/day/user limit catches teams off guard. If you have a flow that runs under a service account and processes hundreds of SharePoint items hourly, you will hit this by midday.

Workaround: Use the SharePoint Send an HTTP request to SharePoint action with batch requests ($batch endpoint) to combine multiple operations into a single request. Or use Dataverse as an intermediary.

Outlook: Sending Limits Are Strict

The 30 emails/minute limit applies to the mailbox, not the connector. If a user also sends emails manually while a flow is sending notifications, the combined volume counts towards the limit.

Workaround: For high-volume email, use a shared mailbox or switch to a dedicated email service (e.g., Brevo, SendGrid) via the HTTP connector.

Dataverse: The 6,000/5-min Aggregate

This limit is aggregate across all Dataverse operations for a user. A single flow run with 50 Dataverse actions, running 20 times in 5 minutes, consumes 1,000 requests. Add a canvas app and a model-driven app running simultaneously and you can hit the ceiling quickly.

Workaround: Use ExecuteMultiple (via the Dataverse Perform a bound/unbound action) to batch multiple operations into fewer requests. Also, restructure flows to reduce per-run Dataverse calls.

Teams: Channel Posting Is Heavily Throttled

At 3 messages per second per channel, any flow that posts updates for each item in a loop will hit throttling almost immediately.

Workaround: Aggregate your updates into a single message. Instead of posting “Task 1 complete”, “Task 2 complete”, “Task 3 complete” — compose a summary and post once.

Strategies for Staying Within Limits

1. Batch Operations Where Possible

Use batch endpoints (SharePoint $batch, Dataverse ExecuteMultiple) to combine many small operations into fewer requests.

2. Add Delays in Loops

When iterating over large datasets, add a Delay action inside your Apply to Each loop. Even 1-2 seconds between iterations can prevent throttling on strict connectors.

3. Use Concurrency Control

Set the Degree of Parallelism on your Apply to Each loop. Running 1-at-a-time (degree 1) is slower but avoids hammering the connector. The default is 20 parallel branches — that can trigger 429s quickly.

4. Implement Paging

For data retrieval, use pagination settings on the action (enable it in Settings) rather than retrieving all records at once.

5. Cache Data Locally

In Power Apps, load data into a collection at app start and work from the collection. Only call the data source when you need to read fresh data or write changes.

6. Monitor Your Usage

Use the Power Platform Admin Centre > Analytics > Dataverse to track API call volumes. Set up alerts when usage approaches 80% of limits.

7. Use Service Accounts Wisely

Spreading requests across multiple service accounts does not bypass per-user limits — it distributes them. This is a legitimate strategy for the 6,000 requests/day Dataverse limit but does not help with connector-level per-connection limits.

8. Switch to Power Automate Per-Flow Licence

If a flow consistently exceeds per-user limits, the per-flow licence (250,000 requests/day shared across the flow) is often the most cost-effective solution.

How to Diagnose Throttling Issues

In Power Automate

Open the failed flow run.
Click on the failed action.
Check the Status code — 429 confirms throttling.
Look at the Retry-After header in the output to see how long the connector asked you to wait.
Check the action repetition count to see how many retries were attempted.

In Power Apps

Open Monitor (in the app editor, click “Monitor” in the toolbar).
Look for data calls with long durations or error responses.
Filter by status code 429.
Check the Network tab for Retry-After headers.

In the Admin Centre

Go to Power Platform Admin Centre > Analytics > Dataverse.
Review the API calls chart for spikes.
Check API calls by user to identify which account is hitting limits.

Quick Reference: When You Hit the Limit

Symptom	Likely Cause	First Action
Flow fails with 429	Connector-level throttle	Reduce concurrency, add delays
Flow fails intermittently	Approaching limit boundary	Monitor usage, add retry policy
App shows “Network error”	Request entitlement exceeded	Check admin centre usage
Multiple flows failing same time	Shared service account at limit	Distribute across accounts
Flow works in test, fails in prod	Volume difference	Load test before deployment
Approvals timing out	Approval connector throttled	Batch approval creation