generated: '2026-09-12'
method: searched
source: >-
  All four published Solo.io OpenAPI contracts in openapi/ (39 operations, every response and
  header read on 2026-09-12), plus the Gloo Portal documentation at
  https://docs.solo.io/gateway/latest/portal/ and the Gloo Edge rate-limiting guides at
  https://docs.solo.io/gloo-edge/latest/guides/security/rate_limiting/
docs: https://docs.solo.io/gloo-edge/latest/guides/security/rate_limiting/
provider: Gloo
providerId: gloo
description: >-
  Published rate limits on Gloo's own APIs: none. This is a correct and expected zero, not a
  documentation gap. Gloo is software the customer deploys — the Gloo Portal server runs in the
  customer's own cluster, so there is no vendor-imposed quota to publish and no vendor to
  enforce one. This file replaces a 2026-05-04 bulk-sweep scaffold that invented a 10
  requests-per-minute free tier with a burst of 20 and a full set of X-RateLimit-* headers.
  None of that appears in any Solo.io contract or document.
limit_count: 0
headers: {}
headers_note: >-
  No RateLimit-*, X-RateLimit-* or Retry-After header is declared on any of the 39 published
  operations, and no 429 response is declared anywhere in the four contracts.
response_codes:
  throttled: null
  quota_exceeded: null
limits: []
inverted_finding:
  note: >-
    The interesting fact runs the other way. Rate limiting is one of Gloo's headline PRODUCT
    capabilities and is modelled as first-class data in Solo's own published contracts — it is
    simply applied to the customer's APIs, by the customer, rather than to Solo's.
  evidence:
    - artifact: openapi/gloo-platform-portal-openapi.yaml
      schema: RateLimitPolicy
      shape: '{ unit: SECOND|MINUTE|HOUR|DAY|MONTH|YEAR, requestsPerUnit: integer }'
      attached_to: UsagePlan.rateLimitPolicy, returned by GetUsagePlans
    - artifact: openapi/gloo-portal-server-openapi.yaml
      schema: RateLimit
      shape: '{ unit: SECOND|MINUTE|HOUR|DAY|MONTH|YEAR, requestsPerUnit: string }'
      note: >-
        Same concept, but requestsPerUnit is typed `string` here and `integer` in the Gloo
        Platform contract — a real divergence between two contracts Solo.io publishes.
    - artifact: projects/gloo/api/v1/enterprise/options/ratelimit/ratelimit.proto
      note: The Envoy rate-limit filter configuration shipped in solo-io/gloo.
    - artifact: projects/gloo/api/v1/options/local_ratelimit/local_ratelimit.proto
      note: Per-instance local rate limiting, distinct from the global rate-limit service.
    - artifact: projects/gloo/api/v1/options/connection_limit/connection_limit.proto
      note: Connection-level limiting.
  docs:
    - https://docs.solo.io/gloo-edge/latest/guides/security/rate_limiting/
gaps:
  - >-
    An agent calling a deployed Gloo Portal cannot discover the operator's limits from the
    contract: no 429 is declared, so it has no documented signal to back off on, and the limits
    that DO apply are whatever UsagePlan the operator attached.
evidence:
  - url: https://docs.solo.io/gloo-edge/latest/guides/security/rate_limiting/
    status: 200
    fetched: '2026-09-12'
  - url: https://docs.solo.io/gateway/latest/portal/
    status: 200
    fetched: '2026-09-12'