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: microsoft-azure-data-factory
providerId: microsoft-azure-data-factory
created: '2026-05-04'
generated: '2026-09-17'
modified: '2026-09-17'
method: searched
source: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/request-limits-and-throttling
docs: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/request-limits-and-throttling
tags:
- Rate Limiting
- Quotas
- Throttling
description: >-
  Published throttling limits for the Azure Data Factory REST API. This replaces a 2026-05-04
  scaffold that asserted invented per-API-key limits (10 rpm free tier, X-RateLimit-* headers).
  Data Factory has no API keys and returns no X-RateLimit-* headers. It is a Microsoft.DataFactory
  resource provider behind Azure Resource Manager, so the real limits are ARM's regional
  token-bucket limits, applied per subscription per service principal per operation type, and the
  real runtime signal is the x-ms-ratelimit-remaining-* family.
headers:
  limit: null
  remaining:
  - x-ms-ratelimit-remaining-subscription-reads
  - x-ms-ratelimit-remaining-subscription-writes
  - x-ms-ratelimit-remaining-subscription-deletes
  - x-ms-ratelimit-remaining-tenant-reads
  - x-ms-ratelimit-remaining-tenant-writes
  - x-ms-ratelimit-remaining-subscription-resource-requests
  - x-ms-ratelimit-remaining-subscription-resource-entities-read
  - x-ms-ratelimit-remaining-tenant-resource-requests
  - x-ms-ratelimit-remaining-tenant-resource-entities-read
  reset: null
  retryAfter: Retry-After
  policy: null
  note: >-
    Read requests return the remaining-reads header, write requests the remaining-writes header,
    delete requests the remaining-deletes header. There is no header carrying the limit itself
    and none carrying a reset timestamp — the bucket refills continuously, so `remaining` plus
    the documented refill rate is the whole runtime signal.
responseCodes:
  throttled: 429
  quotaExceeded: 429
  serviceUnavailable: 503
algorithm: token bucket, applied per region (migrated from per-ARM-instance limits in 2024)
limits:
- name: Subscription reads
  scope: subscription + service principal + region
  metric: requests_per_second
  bucket_size: 250
  refill_rate_per_second: 25
  timeFrame: second
  applies:
  - GET operations on Microsoft.DataFactory
- name: Subscription writes
  scope: subscription + service principal + region
  metric: requests_per_second
  bucket_size: 200
  refill_rate_per_second: 10
  timeFrame: second
  applies:
  - PUT, POST and PATCH operations on Microsoft.DataFactory
- name: Subscription deletes
  scope: subscription + service principal + region
  metric: requests_per_second
  bucket_size: 200
  refill_rate_per_second: 10
  timeFrame: second
  applies:
  - DELETE operations on Microsoft.DataFactory
- name: Tenant reads
  scope: tenant + region
  metric: requests_per_second
  bucket_size: 250
  refill_rate_per_second: 25
  timeFrame: second
- name: Tenant writes
  scope: tenant + region
  metric: requests_per_second
  bucket_size: 200
  refill_rate_per_second: 10
  timeFrame: second
- name: Tenant deletes
  scope: tenant + region
  metric: requests_per_second
  bucket_size: 200
  refill_rate_per_second: 10
  timeFrame: second
global_limits:
  note: >-
    Beyond the per-service-principal limits above there are global per-subscription limits equal
    to 15x the individual service-principal limit for each operation type, applied across all
    service principals. A request is throttled if the global, service-principal or tenant limit
    is exceeded.
  multiplier: 15
caveats:
- Limits may be lower for free or trial subscriptions.
- Resource providers can impose their own limits on top of ARM's. Microsoft does not publish a
  Microsoft.DataFactory-specific throttling table, so the ARM limits above are the only published
  figures that govern this API.
- These limits govern the CONTROL PLANE only. They do not limit pipeline execution, data movement
  throughput or concurrent activity runs, which are governed by separate Data Factory service
  limits and by integration-runtime capacity.
recovery:
  strategy: honour Retry-After, then exponential backoff
  guidance: >-
    On 429 the response carries Retry-After in seconds. Sending before that elapses is not
    processed and returns a fresh retry value. Watch the x-ms-ratelimit-remaining-* header on
    every response and back off before the bucket empties rather than after.
summary:
  limit_count: 6
  headers_published: true
  status_code_on_exhaustion: 429
  retry_after_header: true