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: AppOmni
providerId: appomni
generated: '2026-09-04'
method: searched
source: https://api.appomni.com/ (AppOmni public Postman collection, 24 saved example responses carrying the header)
created: '2026-05-04'
modified: '2026-09-04'
description: >-
  AppOmni returns a live rate-limit signal on every platform API response. It is a single non-standard
  header, `X-RateLimit`, whose value is a used/limit fraction. This replaces a scaffold written by a
  2026-05-04 bulk sweep that invented three tiers of per-minute and per-month quotas AppOmni has never
  published.
headers:
  limit: X-RateLimit
  limit_format: '<used>/<limit>'
  remaining: null
  reset: null
  retryAfter: null
  policy: null
  note: >-
    AppOmni does NOT emit the RFC 9239-style RateLimit-Limit / RateLimit-Remaining / RateLimit-Reset
    triplet, nor X-RateLimit-Limit / -Remaining / -Reset, nor Retry-After. An agent must parse the
    fraction itself: remaining = limit - used. There is no published reset timestamp, so a client
    cannot compute when the window rolls.
responseCodes:
  throttled: 429
  note: >-
    429 is the expected exhaustion status but is NOT demonstrated — none of the 127 saved example
    responses is an error response. Recorded as inferred.
limit_count: 1
limits:
  - name: Platform API request ceiling
    scope: per-token
    scope_confidence: low
    metric: requests
    limit: 2000
    window: unknown
    header: X-RateLimit
    observed_values:
      - 1/2000
      - 2/2000
      - 3/2000
      - 10/2000
      - 11/2000
      - 12/2000
    observed_in: 24 saved example responses across the public Postman collection
    evidence: >-
      Every example response that carries headers carries `X-RateLimit: <n>/2000`. The denominator is
      2000 in all 24 observations. AppOmni publishes no prose describing the window (per minute, hour
      or day) or the scope (per token, per user or per tenant), so both are recorded as unknown rather
      than guessed.
    applies:
      - AppOmni Posture Findings API
      - AppOmni Policies API
      - AppOmni Compliance and Reports API
      - AppOmni Monitored Services API
      - AppOmni Identity and Access API
      - AppOmni Discovery, Insights and Audit API
      - AppOmni Developer Platform API
policies:
  - name: Per-service sync rate limiting
    description: >-
      Separate from the API request ceiling. AppOmni rate-limits data resync of monitored services:
      "Affected by rate_limits and availability. Data syncs are enqueued. Only syncs with
      'allow_adhoc_refresh: true' and 'rate_limited: false' will be requested." Check
      GET /api/v1/{serviceType}/{serviceType}org/{id}/sync_timestamps/ (operationId dataSyncs) before
      calling requestSyncDataType — the response carries the rate_limited flag per timestamp field.
    source: https://api.appomni.com/
gaps:
  - No documented window for the 2000 ceiling.
  - No documented scope for the 2000 ceiling.
  - No Retry-After and no reset timestamp, so backoff cannot be computed from the response.
  - No published rate-limit page in AppOmni's public documentation; the only evidence is the header
    captured in AppOmni's own example responses.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com