How is the "Tenant license count" computed for SharePoint Graph API capacity bands?

MS 0 Reputation points
2026-10-26T17:05:07.4033333+00:00

Hello,

We are building an application that calls the Microsoft Graph API for SharePoint and OneDrive (/v1.0/sites and /v1.0/drives). We are implementing client-side rate limiting to stay within the published SharePoint capacity bands (e.g., 1,250 RU/min for 0-1k seats, 2,500 RU/min for 1k-5k seats, etc.).

To calculate a tenant's capacity budget programmatically, our app queries GET /v1.0/subscribedSkus. However, we are seeking engineering clarification on how the backend evaluates the "Tenant license count" in a few specific scenarios:

  1. Purchased vs. Assigned: Does the backend rate limiter base the capacity band on purchased inventory (prepaidUnits.enabled) or actively assigned users (consumedUnits)?
  2. Unbundled Teams SKUs: If a tenant has 2,000 users, and each user is assigned both an "Office 365 E1 (No Teams)" license and a "Teams Enterprise Standalone" license, does the backend deduplicate this to 2,000 seats, or does it sum the SKUs to 4,000 seats?
  3. License Scope: Does the capacity band only count base SharePoint/OneDrive licenses, or does it aggregate other commercial workloads (like standalone Exchange, Intune, Entra ID, or Power Apps)?
  4. Free/Included Tiers: Does the engine automatically ignore zero-cost or unassigned utility SKUs (like FLOW_FREE or Power BI Standard) when calculating the tenant's tier?

Any insight into how the backend computes these specific edge cases would be greatly appreciated so we can ensure our application paces its requests correctly. Thank you!

Microsoft 365 and Office | SharePoint | Development
0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest
  1. Kai-L 21,095 Reputation points Microsoft External Staff Moderator
    2026-10-26T17:49:04.1733333+00:00

    Hello MS,

    As forum moderator, I am not able to confirm how the SharePoint throttling service calculates license counts internally. My role here is limited to what Microsoft has documented publicly. From my research, application limits are based on the number of licenses purchased per organization, using the plans listed on SharePoint Limits. However, Microsoft does not document the exact algorithm for SKU overlap, user deduplication, standalone workload licenses or free SKUs. Here is how the published guidance relates to each of your scenarios:

    • Purchased versus assigned: The wording points to purchased licenses, so prepaidUnits.enabled is conceptually closer than consumedUnits. In Microsoft Graph, consumedUnits is the number of assigned licenses, while prepaidUnits.enabled is the number of units enabled for the active subscription. Summing prepaidUnits.enabled locally still isn't guaranteed to match SharePoint's internal count. /subscribedSkus shows commercial subscription inventory, not the normalized value the throttling service uses.
    • No Teams and standalone Teams licenses: The documentation is ambiguous here. The application throttling section refers to licenses purchased, while the Multi-Geo note refers to the total tenant user license count. There is no published rule confirming whether seats are deduplicated per user. A standalone Teams SKU wouldn't logically add SharePoint capacity if it doesn't include a qualifying SharePoint service plan, but Microsoft hasn't confirmed this SKU by SKU.
    • Which workloads count: The guidance points to licenses included in the SharePoint Online plans, not every commercial SKU in the tenant. Standalone Exchange Online, Intune, Entra ID, Power Apps or Teams inventory shouldn't be treated as SharePoint capacity just because it appears in /subscribedSkus.
    • Free and utility SKUs: There is no public allowlist or denylist for SKUs such as FLOW_FREE or free Power BI. The documentation only says Microsoft may lower limits for unpaid or unlicensed usage.

    For your rate limiter, I'd treat the license band as an estimate rather than a hard budget. Multiple applications in the same tenant share the same resource bucket, so you can still be throttled below your calculated limit. SharePoint Online also doesn't support IETF RateLimit headers, so your app should always honor the Retry-After header on 429 and 503 responses.

    For reference: 

    subscribedSku resource type - Microsoft Graph v1.0 | Microsoft Learn

    List subscribedSkus - Microsoft Graph v1.0 | Microsoft Learn

    Avoid getting throttled or blocked in SharePoint Online | Microsoft Learn

    If you need an authoritative answer for these edge cases, I recommend that the Global Admin in your organization create a service request with Microsoft Support. Please keep in mind that support may not be able to share internal service logic. For detailed instructions on how to get support, please refer to Get support - Microsoft 365 admin. If you don't know who your IT administrator is, please refer to this article: How do I find my Microsoft 365 admin? - Microsoft Support 

    I hope this information is helpful and provide you with a clear path forward. Should you have any further questions or need additional assistance, please don't hesitate to reach out. I'm always happy to help. Have a wonderful day! 

    If the answer is helpful, please click "Yes" and kindly upvote it. If you have extra questions about this answer, please click "Comment".  

    Note: Please follow the steps in the forum documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.