Microsoft Purview · Rate Limits

Microsoft Purview Rate Limits

Microsoft Purview APIs sit on the Azure Resource Manager and Microsoft Graph control planes, inheriting their throttling models. ARM control-plane requests are subject to subscription-level read / write limits (12,000 reads, 1,200 writes per hour per subscription per region); Graph compliance endpoints follow Graph throttling. Purview-specific data-plane limits are not separately published per-tier — they degrade based on Data Map capacity-unit allocation. Limits are enforced via 429 with Retry-After.

Microsoft Purview Rate Limits is the machine-readable rate-limit profile for Microsoft Purview on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring requests_per_hour and varies.

The profile also includes 4 backoff/retry policies defined and response codes documented for throttled and serviceUnavailable.

Tagged areas include Rate Limiting, Compliance, Data Governance, and Microsoft.

4 Limits Throttle: 429
Rate LimitingComplianceData GovernanceMicrosoft

Limits

Azure Resource Manager reads (subscription / region) account/region
requests_per_hour · hour
12000
Default ARM control-plane read budget per subscription per region.
Azure Resource Manager writes (subscription / region) account/region
requests_per_hour · hour
1200
Default ARM control-plane write budget per subscription per region.
Microsoft Graph (Purview compliance endpoints) account
varies
See Microsoft Graph throttling guidance — service- and tenant-specific
Purview Data Map / scanning account
varies
Capacity bound by allocated Data Map capacity units; degrades when capacity is exhausted

Policies

Honor Retry-After
All 429 responses include Retry-After. Implement exponential backoff with jitter on top of the header value.
Use ARM rate-limit headers
Inspect x-ms-ratelimit-remaining-subscription-reads / -writes to back off proactively before hitting the cap.
Capacity scaling
Increase allocated Data Map capacity units to raise effective Purview data-plane throughput.
Service principal scoping
Use a dedicated service principal per ETL pipeline to isolate throttling impact and improve diagnosability.

Sources