generated: '2026-09-05'
method: probed
source: >-
  Live unauthenticated responses observed 2026-09-05 —
  https://ubuntu.com/security/releases.json,
  https://api.charmhub.io/v2/charms/info/postgresql-k8s,
  https://api.snapcraft.io/v2/snaps/info/hello — cross-checked against
  https://api.snapcraft.io/docs, https://api.charmhub.io/docs and the thirteen specs in openapi/.
provider: Canonical
providerId: canonical
description: >-
  Canonical publishes no rate limits for any of its APIs, and its APIs emit no rate-limit response
  headers. This is an honest zero, measured rather than assumed: the observed responses carry
  request-tracing headers but nothing an agent could use to pace itself or to back off.
  NOTE: this file replaces a 2026-05-04 bulk-sweep scaffold that asserted X-RateLimit-* headers and
  per-tier request-per-minute figures Canonical has never published.
limit_count: 0
documented: false
headers:
  limit: null
  remaining: null
  reset: null
  retry_after: null
  policy: null
  observed_instead:
    - x-request-id
    - x-vcs-revision
    - x-view-name
    - snap-store-version
  note: >-
    The Snap Store / Charmhub edge returns x-request-id and x-vcs-revision; ubuntu.com returns
    x-request-id, x-view-name and a cache-control of `max-age=60, stale-while-revalidate=86400,
    stale-if-error=300`. None of these is a rate-limit signal. The cache-control directive is the
    closest thing to published pacing guidance in the portfolio: it tells a client the security
    feeds are refreshed on a 60-second cycle, so polling faster than that gains nothing.
response_codes:
  throttled: null
  note: >-
    No 429 response is declared in any of the thirteen harvested specs. The only 5xx capacity signals
    declared are a Pebble 502 (check unhealthy) and an Anbox Stream Gateway 503 (gateway not fully
    started).
limits: []
probes:
  - url: https://ubuntu.com/security/releases.json
    status: 200
    rate_limit_headers: none
    note: 'Returned cache-control: max-age=60, stale-while-revalidate=86400, stale-if-error=300.'
  - url: https://api.charmhub.io/v2/charms/info/postgresql-k8s
    status: 200
    rate_limit_headers: none
  - url: https://api.snapcraft.io/v2/snaps/info/hello?fields=name
    status: 400
    rate_limit_headers: none
    note: >-
      400 is the correct measured result, not a failure — the Snap Store Device API requires a
      Snap-Device-Series header and says so in the error body.
guidance_for_agents:
  - There is no published budget, so treat every Canonical API as unbounded-but-unpromised: back off on any 5xx and honour the cache-control window on the ubuntu.com security feeds.
  - LXD and snapd are software the caller runs; their limits are the host's, not Canonical's.
gaps:
  - No rate limits documented on any Canonical developer page.
  - No RateLimit-* or Retry-After headers on any probed response.
  - No 429 declared in any published contract.