Power Platform throttling and 429 errors

Every Dynamics 365 API surface — Dataverse's Web API, Business Central's API, individual Power Automate connectors — enforces request limits to protect shared platform capacity: a maximum number of API calls per user (or per connection) per rolling 24-hour window, plus shorter burst/spike limits. A 429 Too Many Requests response means a limit was hit, and the fix is almost always architectural, not a support ticket asking for a higher limit.

Dataverse API limit exceeded (0x80072322 / "Number of requests exceeded the limit")

Symptom. Calls to the Dataverse Web API — from a flow, a plug-in, an external integration, or a Power Apps canvas app — start failing with a rate-limit-specific error after a period of high activity.

Cause. Dataverse enforces a rolling limit on requests, execution time, and concurrent requests per user within a 5-minute and 24-hour window. A single high-volume integration (or several integrations sharing one service account identity) can exhaust it.

Fix. Respect the Retry-After header Dataverse returns with a 429 and back off for that duration before retrying, rather than retrying immediately (which just re-triggers the limit). For a sustained high-volume need, batch requests (Dataverse's batch/$batch operations count as fewer requests than the equivalent individual calls) instead of one call per record.

Prevention. Give high-volume integrations their own dedicated service account rather than sharing one identity across several integrations or flows — since the limit is per-user, splitting load across separate identities (where the licensing and governance model allows it) genuinely raises the effective ceiling.

Power Automate connector throttling ("429: rate limit is exceeded")

Symptom. A flow using a specific connector (Dataverse, SharePoint, an HTTP action, a third-party service) starts failing intermittently, often correlating with a burst of trigger activity.

Cause. Each connector enforces its own request limits per user per 24 hours plus a shorter burst limit; a flow triggered in a tight loop (a "for each" over hundreds of items, each making its own connector call) can exhaust the burst limit within seconds even while comfortably under the 24-hour ceiling.

Fix. Add a retry policy with exponential backoff on the action (Power Automate supports this natively per-action), and where possible batch operations instead of calling the connector once per loop iteration — many connectors' bulk/batch actions exist specifically to reduce request counts for this reason.

Prevention. Design flows that process a "for each" over more than a handful of items with the connector's batch capability from the start, rather than retrofitting retry logic after the first throttling incident in production.

Business Central API 429 responses

Symptom. An external integration against the Business Central API starts receiving 429 responses under sustained load.

Cause. Business Central enforces its own per-user, per-24-hour request limits on the API surface, generous for typical integration volumes but real for high-frequency polling or bulk-sync patterns.

Fix. Reduce polling frequency where a webhook-based push model (see webhooks in Business Central) can replace frequent polling, and implement retry-with-backoff on 429 responses the same way as any other throttled API.

Prevention. Prefer event-driven integration (webhooks, business events) over tight polling loops wherever the integration pattern allows it — polling scales request volume with time, while an event-driven pattern scales with actual business activity, which is almost always lower.

Retrying too aggressively makes throttling worse, not better

Symptom. A system experiencing intermittent 429s gets progressively worse rather than recovering, sometimes cascading into a broader outage.

Cause. A naive retry loop with no backoff (retry immediately, forever) adds more requests on top of an already-throttled account, which can extend or worsen the throttling window rather than letting it clear.

Fix. Implement exponential backoff with jitter (increasing wait time between retries, with some randomness to avoid synchronized retry storms across multiple callers) rather than fixed-interval or immediate retries.

Prevention. Treat retry-with-backoff as a mandatory design element for any integration against a rate-limited API, not an afterthought added after the first production incident — see retry policies with Azure services for the pattern in more depth.

Where to go next

The connector licensing and selection context is in Power Automate connectors for Dynamics 365; the wider resilience pattern set is in retry policies with Azure services and circuit breakers in Dynamics 365 integrations.