specification: API Commons Rate Limits
specificationVersion: '0.1'
schema: https://raw.githubusercontent.com/api-evangelist/interface-research/main/schema/api-commons.yml#/$defs/RateLimits
provider: Power Query
providerId: power-query
generated: '2026-08-29'
method: searched
source: https://learn.microsoft.com/en-us/rest/api/fabric/articles/throttling
docs: https://learn.microsoft.com/en-us/rest/api/fabric/articles/throttling
created: '2026-05-04'
modified: '2026-08-29'
provenance_note: >-
  Replaces the 2026-05-04 bulk-sweep scaffold, which invented free/professional/
  enterprise tiers, X-RateLimit-* headers and per-minute numbers Microsoft does
  not publish. Everything below is read from Microsoft's own throttling article,
  probed 2026-08-29 (HTTP 200).
tags:
  - Business Intelligence
  - Data Integration
  - Microsoft Fabric
  - Rate Limiting
  - Quotas
  - Throttling
description: >-
  Rate limits for the Power Query programmatic surface (the Fabric Dataflow REST
  API). Fabric enforces a Unified Quota model: quota is tracked per IDENTITY —
  a user, service principal or managed identity — not per API key, not per
  capacity, and never shared between identities. Three independent quota buckets
  cover Platform APIs, Job Scheduler APIs and Long-Running Operation APIs, each
  at 200 calls per minute, in a fixed 60-second window that replenishes all at
  once rather than sliding. Individual endpoints may impose additional limits on
  top of the shared quota; both are evaluated and the most restrictive wins.
model: unified-quota-per-identity
scope: identity (user | service principal | managed identity)
window:
  type: fixed
  length: 60 seconds
  replenishment: >-
    All at once at the end of the window. Quota does NOT recover gradually — an
    identity that exhausts its bucket at second 1 receives 429 for the remaining
    59 seconds.
headers:
  retryAfter: Retry-After
  limit: null
  remaining: null
  reset: null
  policy: null
headers_note: >-
  Fabric publishes NO budget headers. There is no RateLimit-Limit,
  RateLimit-Remaining, RateLimit-Reset or X-RateLimit-* on this surface. The only
  runtime signal is Retry-After on a 429, which means a client cannot see how
  close it is to the ceiling until it has already crossed it. This is the single
  biggest agent-readiness gap on the Power Query API.
responseCodes:
  throttled: 429
  quotaExceeded: 429
limits:
  - name: Unified Quota for Platform APIs
    scope: identity
    metric: requests_per_minute
    limit: 200
    timeFrame: minute
    applies:
      - Items_ListDataflows
      - Items_CreateDataflow
      - Items_GetDataflow
      - Items_UpdateDataflow
      - Items_DeleteDataflow
      - Items_GetDataflowDefinition
      - Items_UpdateDataflowDefinition
      - Items_DiscoverDataflowParameters
  - name: Unified Quota for Job Scheduler APIs
    scope: identity
    metric: requests_per_minute
    limit: 200
    timeFrame: minute
    applies:
      - BackgroundJobs_ScheduleExecute
      - BackgroundJobs_ScheduleApplyChanges
      - BackgroundJobs_RunOnDemandExecute
      - BackgroundJobs_RunOnDemandApplyChanges
  - name: Unified Quota for Long-Running Operations APIs
    scope: identity
    metric: requests_per_minute
    limit: 200
    timeFrame: minute
    applies:
      - operation polling via Location / x-ms-operation-id on 202 responses
      - QueryExecution_ExecuteQuery
limit_count: 3
other_limits:
  - name: Query execution timeout
    operation: QueryExecution_ExecuteQuery
    limit: 90 seconds
    source: https://learn.microsoft.com/en-us/rest/api/fabric/dataflow/query-execution/execute-query
  - name: Schedules per item
    operation: BackgroundJobs_ScheduleExecute / BackgroundJobs_ScheduleApplyChanges
    limit: null
    note: >-
      A ceiling exists — errorCode ScheduleExceedsLimit, "The number of created
      schedules for the item exceeds the limit" — but the number is not published.
  - name: On-demand job requests
    operation: BackgroundJobs_RunOnDemandExecute / BackgroundJobs_RunOnDemandApplyChanges
    limit: null
    note: >-
      errorCode TooManyRequestsForJobs, "The caller requests too many on-demand
      job requests". Number not published.
policies:
  - name: Dual enforcement
    description: >-
      Every request is evaluated against BOTH the identity-level Unified Quota
      and any endpoint-specific limit. The most restrictive wins.
  - name: Independent buckets
    description: >-
      Consuming the Job Scheduler quota does not consume Platform quota. A
      high-volume job workload cannot starve general item operations.
  - name: Identity isolation
    description: >-
      Quotas are never shared between identities. One throttled service principal
      does not affect any other caller.
  - name: Honor Retry-After
    description: >-
      Microsoft's stated guidance: honor Retry-After, apply bounded retries, and
      avoid bursts. Distributing requests evenly across the 60-second window is
      the documented way to avoid throttling.
  - name: Quota is not capacity
    description: >-
      Microsoft states explicitly that APIs Quota governs request rate only. It
      does not represent Fabric compute, storage or billing capacity and has no
      effect on cost.
evidence:
  - url: https://learn.microsoft.com/en-us/rest/api/fabric/articles/throttling
    status: 200
  - url: https://learn.microsoft.com/en-us/rest/api/fabric/dataflow/query-execution/execute-query
    status: 200
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com
    url: https://apievangelist.com