Microsoft Active Directory · Rate Limits

Active Directory Rate Limits

Microsoft Entra ID (Azure AD) directory operations are accessed through Microsoft Graph, which throttles using a token-bucket algorithm based on ResourceUnits. Limits are scoped per application, per (application + tenant) pair, and per tenant for writes. Tenant size (S < 50 users, M 50–500, L > 500) affects the read budget. 429 responses include a Retry-After header. For bulk extraction Microsoft recommends Microsoft Graph Data Connect rather than the REST APIs.

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

It captures 7 rate-limit definitions, measuring resource-units and requests.

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

Tagged areas include Active Directory, Authentication, Authorization, Directory Services, and Identity Management.

7 Limits Throttle: 429
Active DirectoryAuthenticationAuthorizationDirectory ServicesIdentity ManagementMicrosoft EntraRate Limiting

Limits

Entra read budget — Application + Tenant pair (Small tenant <50 users) app+tenant
resource-units · 10s
3500
10-second sliding window. Most GET requests cost 1 ResourceUnit; GET /applications costs 2; $select reduces cost by 1; $expand increases cost by 1.
Entra read budget — Application + Tenant pair (Medium tenant 50–500 users) app+tenant
resource-units · 10s
5000
Entra read budget — Application + Tenant pair (Large tenant >500 users) app+tenant
resource-units · 10s
8000
Entra read budget — Application (across all tenants) application
resource-units · 20s
150000
Entra write budget — Application + Tenant pair app+tenant
requests · 150s
3000
2 minutes 30 seconds window for POST / PATCH / PUT / DELETE on directory objects.
Entra write budget — Application application
requests · 300s
35000
Entra write budget — Tenant tenant
requests · 300s
18000

Policies

Retry-After
Wait the number of seconds returned in the Retry-After header before retrying. Microsoft Graph SDKs implement this automatically.
Exponential Backoff Fallback
If no Retry-After header is returned, fall back to exponential backoff with jitter.
Avoid Polling
Use change tracking (delta queries) and change notifications (webhooks) instead of polling directory collections.
Batch Carefully
JSON batching evaluates each sub-request against limits independently; throttled sub-requests must be retried using the Retry-After header from the inner response (not the outer 200 OK envelope).
Bulk via Data Connect
For bulk extraction of users, groups, or activity data use Microsoft Graph Data Connect rather than the REST APIs to avoid throttling.
Header Watching
Monitor x-ms-throttle-limit-percentage; values approaching 1.0 indicate imminent throttling.

Sources