Throttling in Microsoft Fabric

Microsoft Fabric uses throttling to maintain service performance and reliability when workloads exceed capacity or REST API request limits. This article explains how throttling works, how to interpret HTTP 429 responses, and how to design applications that handle Fabric API quotas effectively.

API quota limits

Microsoft Fabric is introducing Unified Quota for REST APIs for its REST APIs. Under this model, API requests are governed by identity-level quotas enforced per User or Service Principal.

The goal is a consistent, predictable throttling experience for the governed API groups, across automation, CI/CD, and agent-driven scenarios.

Previously, each Microsoft Fabric REST API enforced its own independent throttling rules, which often resulted in inconsistent behavior across endpoints. As a result, it was difficult to predict when a workload might be throttled, especially for automation scenarios that interacted with multiple APIs and were subject to different limits.

With the introduction of APIs Quota, Fabric is moving to a more consistent, identity-based approach. API consumption is now governed by a unified quota that is enforced per identity, providing a clearer and more predictable throttling model across Fabric APIs. However, it's important to note that some individual API-specific throttling limits may still apply in addition to the overall APIs Quota.

When an API reference page documents a quota, treat that endpoint-specific limit as authoritative for that API. If an API reference page doesn't list a numeric quota, design your application to handle 429 responses by honoring Retry-After, applying bounded retries, and avoiding burst s.

How the Quota Model Works

Each identity—either a user or a service principal—is assigned multiple independent quota buckets that govern different categories of API traffic. When the identity sends a request, the request is evaluated against the quota for the API category being used.

There are three Unified Quotas:

1. Unified Quota for Platform APIs — dedicated to Platform APIs.
2. Unified Quota for Job Scheduler APIs — dedicated to Job Scheduler APIs.
3. Unified Quota for Long-Running Operations APIs — dedicated to Long-Running Operations APIs.

Because these quotas are independent, activity in one category does not consume quota from another category. For example, a service principal could consume its full Unified Quota for Job Scheduler APIs without affecting its available Unified Quota for Platform APIs. This separation ensures that high-volume workloads in specialized API areas do not impact general API operations and enables more predictable throttling behavior across different types of requests.

API enforcement

The APIs Quota is enforced on a per-identity basis, meaning that every user, service principal, or managed identity receives its own independent quota allocation. Quotas are never shared between identities, and all eligible Fabric APIs consume from a common quota bucket associated with that identity.

As a result, API usage by one identity has no impact on any other identity. For example, a heavily used service principal can exhaust its own APIs Quota without affecting the quotas of other users or applications.

Likewise, if an identity reaches its quota limit and is throttled, that throttling applies only to that identity, while other identities continue to operate normally. This isolation provides more predictable and manageable API consumption across workloads.

Quota enforcement hierarchy

Every API request begins with an identity—either a user account or a service principal. When that identity calls a Fabric API, the request first consumes capacity from the shared APIs Quota, which is enforced per identity rather than per API. This quota acts as a centralized throttling mechanism that is shared across all participating APIs, ensuring that a single identity cannot exceed its allocated request rate.

After the request is evaluated against the shared APIs Quota, any API-specific throttling limits are also applied. These limits are independent of the shared quota and may exist only for certain APIs. As a result, a request must satisfy both the identity-level APIs Quota and any applicable individual API limits to be successfully processed.

In practical terms, the shared APIs Quota provides a consistent throttling experience across APIs, while individual API limits continue to protect specific services that require additional safeguards. An API call can therefore be throttled either because the identity has exhausted its shared quota or because it has reached the limit of a particular API endpoint.

Key concepts:

• Identity-based enforcement: Quota is tracked separately for each user or service principal.
• Shared across APIs: Requests to different APIs consume from the same APIs Quota pool.
• Throttling only: The APIs Quota controls request rates but does not affect authorization or permissions.
• Dual enforcement: Both the shared APIs Quota and any API-specific limits are evaluated for every request.
• Most restrictive limit wins: A request is throttled when either the shared quota or an applicable API-specific limit is exceeded.

How Quota Is Consumed

Every API request consumes quota from the calling identity's APIs Quota bucket. All requests made by that identity count toward the same shared quota, regardless of which API is called.

Quota Window and Renewal

APIs Quota is enforced using a fixed 60-second window. The quota bucket is replenished all at once when the current window ends. Quota does not gradually recover during the window.

Timeline Example

Second 0   → Quota window begins. Bucket is full (300 requests available).
Second 1   → 300 requests are made. Bucket is exhausted.
             Additional requests receive HTTP 429 (Too Many Requests).

Seconds 2-59 → All additional requests continue to receive HTTP 429.
               No quota is restored during the window.

Second 60  → New quota window begins.
             Bucket is fully replenished (300 requests available).
             Requests are accepted again.

Practical Implications

• Bursting requests at the start of a window is allowed, but doing so may leave the identity throttled for the remainder of that window.
• Distributing requests evenly across the 60-second period helps avoid throttling.
• Always honor the Retry-After response header. It indicates how long to wait before retrying a throttled request.

Rate limit details by API

While Microsoft Fabric provides unified throttling categories and shared quota concepts, the actual rate limits can vary by API. Always check the Throttling limits section for the specific API you're calling.

Throttling message

When throttling occurs, Fabric returns an HTTP status code 429 (Too many requests). Fabric returns a 429 status code for two distinct reasons, each identified by a different errorCode in the response body:

• Rate limit exceeded (RequestBlocked)
• Capacity limit exceeded (CapacityLimitExceeded)

Inspect the errorCode value in the response to determine which condition occurred and how to respond.

Rate limit exceeded (RequestBlocked)

When a user sends many requests that exceed a predetermined limit during a time window, Fabric throttles further requests from that user for a short period.

In this case, Fabric returns an HTTP status code 429 (Too many requests) with a Retry-After HTTP header in the response, indicating how many seconds the calling application should wait before retrying the call. The response body uses the RequestBlocked error code:

{
    "errorCode": "RequestBlocked",
    "message": "Request is blocked by the upstream service until: 2/18/2026 10:45:04 PM (UTC)"
}

When you receive this error, wait for the duration specified in the Retry-After header before retrying the request.

The following screenshot shows a response example, suggesting that the user waits 55 seconds before retrying the call.

Capacity limit exceeded (CapacityLimitExceeded)

Fabric also returns an HTTP status code 429 (Too many requests) when your organization's Fabric capacity has exceeded its limits. Unlike rate limiting, this throttling isn't caused by the number of API calls a specific caller makes. Instead, it occurs when the compute (capacity units) consumed on your capacity exceeds the limits of the purchased Fabric SKU. The response body uses the CapacityLimitExceeded error code:

{
    "errorCode": "CapacityLimitExceeded",
    "message": "Your organization's Fabric compute capacity has exceeded its limits. Try again later."
}

When you receive this error, try the request again later. Because this throttling depends on the overall compute consumed on your capacity rather than your individual request rate, retrying immediately is unlikely to succeed until the capacity's compute usage falls back within its limits. If you encounter this error frequently, consider scaling up or scaling out your Fabric capacity. For more information about capacity units, SKUs, and how Fabric capacity is consumed, see Plan your capacity size.

Considerations and limitations

Every Fabric admin and core public API can be throttled.

Keep these considerations in mind when you design applications that call Fabric REST APIs:

• Quotas are enforced for the caller identity and API being called. Separate identities don't necessarily share the same request counter, but each caller must still follow the documented limits for the API.
• Many rate limits are evaluated over one-minute windows. If you exceed a limit, wait for the Retry-After value before sending more requests.
• Capacity throttling is different from request-rate throttling. CapacityLimitExceeded indicates that the Fabric capacity is overloaded, not that the caller exceeded a per-minute API quota.
• Retrying a capacity throttling error immediately is unlikely to succeed. Use a bounded retry policy and investigate capacity usage if the error persists.
• For high-volume integrations, prefer list, bulk, or batch operations when they're available, cache metadata that changes infrequently, and spread requests evenly over time.
• For APIs that support pagination, use continuation tokens instead of making repeated broad queries from the beginning.

Frequently asked questions

How do I know whether I reached an API quota or a capacity limit?

Check the errorCode in the 429 response body. RequestBlocked means the request rate exceeded the service's throttling limits. CapacityLimitExceeded means the compute consumed on the Fabric capacity exceeded the limits of the purchased SKU.

When does my quota reset?

Many Fabric REST API rate limits are evaluated over one-minute windows. If the response includes a Retry-After header, use that value as the authoritative wait time before retrying.

Can I check my remaining API quota before making a request?

Fabric REST API responses don't provide a general remaining-quota counter for all APIs. Build clients so they can detect 429 responses, honor Retry-After, and reduce request volume when throttling occurs.

How can I reduce the chance of being throttled?

Use bulk and batch operations when available, prefer list APIs over many single-resource calls, cache frequently accessed metadata, and avoid sudden traffic bursts. For persistent capacity throttling, use the Microsoft Fabric Capacity Metrics app to identify overloaded capacities and workloads.

Should I retry every 429 response the same way?

No. For RequestBlocked, wait for the Retry-After header and then retry with a bounded retry policy. For CapacityLimitExceeded, retry later with exponential backoff and investigate capacity utilization if the problem continues.

Related content

• Using the Microsoft Fabric REST APIs
• Scopes
• Troubleshoot Microsoft Fabric REST APIs
• Plan your capacity size
• Understand your Fabric capacity throttling
• Microsoft Fabric Capacity Metrics app