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: Delta Lake
providerId: delta-lake
generated: '2026-09-05'
method: searched
source: >-
  https://github.com/delta-io/delta-sharing/blob/main/PROTOCOL.md and
  openapi/delta-lake-delta-sharing-protocol-openapi.yml (both read in full, 2026-09-05)
created: '2026-05-04'
modified: '2026-09-05'
tags:
  - Data
  - Data Lake
  - Lakehouse
  - Linux Foundation
  - Open Source
  - Storage
  - Streaming
  - Rate Limiting
description: >-
  The Delta Sharing protocol publishes no rate limits. Neither the normative PROTOCOL.md nor
  the first-party OpenAPI defines a 429 response, a Retry-After header, or any RateLimit-* or
  X-RateLimit-* response header. This is structural rather than an omission: Delta Sharing is a
  self-hosted protocol, so throttling is a property of whoever operates a given sharing server,
  not of the specification.
limit_count: 0
limits: []
headers: {}
responseCodes: {}
documented_status_codes:
  - 200
  - 400
  - 401
  - 403
  - 404
  - 500
note: >-
  This file previously carried scaffold per-tier limits and X-RateLimit-* headers written by
  the 2026-05-04 bulk sweep. Those values were never published by Delta Lake and were removed on
  2026-09-05. An agent calling a Delta Sharing server gets no runtime throttling signal at all:
  there is no header to read and no defined exhaustion status, so back off on 5xx and pace
  conservatively. Recorded as an honest zero.
pagination_note: >-
  The only volume control the protocol defines is pagination — maxResults / pageToken with a
  nextPageToken response field, and a limitHint in the QueryTable body. See
  conventions/delta-lake-conventions.yml.