Graph API Throttling limits for/dataSecurityAndGovernance/protectionScopes/compute and /processContent API's

Hi @Sarathprasath Krishnaswamy

At present, Microsoft Graph does not publish any service-specific throttling limits for the following Purview endpoints:

• /dataSecurityAndGovernance/protectionScopes/compute
• /dataSecurityAndGovernance/processContent

Since these endpoints are not listed in the service-specific throttling documentation, there is no dedicated quota documented for them today. However, that does not mean they are unthrottled. They are still governed by the standard Microsoft Graph throttling model, where requests can be evaluated against multiple limits (such as global, per-app, or per-user), and the first limit reached will trigger throttling.

In practice, you should expect normal Graph behavior. If your request rate is high or bursty, you may receive responses such as 429 Too Many Requests or 503 Service Unavailable, along with a Retry-After header indicating when to retry. This applies even though there is no service-specific entry for these APIs.

From an implementation perspective, the safest approach is to design your solution to handle throttling gracefully. This means honoring the Retry-After header, implementing exponential backoff for retries, and avoiding tight polling loops especially repeated calls to processContent or compute when the policy state has not changed. Where possible, reuse results (for example, caching compute responses) and distribute requests more evenly instead of sending large bursts.

While there are no published service-specific throttling limits for these Purview APIs, they still follow standard Microsoft Graph throttling behavior, and your application should be designed accordingly.

Hope this helps, Please let us know if you have any questions and concerns.

For the /dataSecurityAndGovernance/protectionScopes/compute and /dataSecurityAndGovernance/processContent APIs, there are no additional, service‑specific throttling limits documented in the provided material.

From the available throttling documentation:

• Service‑specific limits are explicitly listed for several areas (for example, Security detections and incidents under /security, Identity and access, Identity and access reports, Excel, Subscription, Service Communications).
• The security section only documents limits for operations on alert, securityActions, secureScore, secureScorecontrolProfile, tiIndicator, and eDiscovery cases under /security/eDiscoveryCases.
• No separate limits are listed for the dataSecurityAndGovernance endpoints in the provided context.

Given this, only the general/global Microsoft Graph throttling model and any applicable high‑level limits (such as application, tenant, or application+tenant resource unit quotas where relevant) should be assumed to apply. There is no evidence in the provided documentation of stricter, dedicated limits for /dataSecurityAndGovernance/protectionScopes/compute or /dataSecurityAndGovernance/processContent beyond those global mechanisms.

When designing the custom app, plan for:

• Standard Graph throttling behavior (HTTP 429 responses) and backoff/retry logic as described in the general throttling guidance.
• The possibility that some resource types can have stricter limits for security reasons, as noted for Microsoft Entra External ID and some Graph APIs; if these endpoints are critical and high‑volume, be prepared to monitor for 429s and adjust throughput or open a support ticket if needed.

No additional, specific numeric limits for these two APIs are present in the supplied documentation.

References:

• Microsoft Graph service-specific throttling limits
• Microsoft Entra External ID deployment guide for tenant design