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: Oracle Health Data Intelligence
providerId: oracle-health-data-intelligence
generated: '2026-08-27'
created: '2026-05-04'
modified: '2026-08-27'
method: searched
source: https://docs.healtheintent.com/#what-does-it-mean-when-an-api-returns-an-http-429-status-code
docs: https://docs.healtheintent.com/#what-does-it-mean-when-an-api-returns-an-http-429-status-code
tags:
  - Genomic
  - Health Records
  - Healthcare
  - Rate Limiting
  - Throttling
description: >-
  Published rate-limit posture for the Oracle Health Data Intelligence APIs. Oracle confirms in its
  own FAQ that it throttles these APIs and returns HTTP 429, but publishes no numeric limit, no
  window, no burst allowance and no response-header contract. This file replaces a 2026-05-04 bulk
  scaffold that carried invented per-tier numbers (10 requests/minute free, and similar) which the
  provider has never published.
limit_count: 0
throttling_documented: true
provider_statement:
  quote: >-
    Oracle intentionally rate limits (or throttles) Health Data Intelligence API requests to help
    maintain the performance of the services. If the request rate exceeds a safe threshold, an HTTP
    429 status code is returned in the response. When a requesting system receives this error, the
    system should retry the original request. To minimize this error, Oracle recommends that the
    requesting system uses an exponential backoff retry algorithm in which the system waits
    progressively longer between reattempts.
  source: https://docs.healtheintent.com/
  observed: '2026-08-27'
limits: []
headers:
  documented: []
  observed: []
  note: >-
    No X-RateLimit-*, no RateLimit-*, and no Retry-After is documented. A live unauthenticated
    request to the cernerdemo tenant on 2026-08-27 returned only date, content-type,
    cerner-correlation-id and www-authenticate — no rate-limit header of any kind.
responseCodes:
  throttled: 429
  serviceUnavailable: 503
  spec: https://tools.ietf.org/html/rfc6585#section-4
recovery:
  strategy: client-side exponential backoff
  retry_after_provided: false
  note: >-
    Because no Retry-After and no reset timestamp is emitted, a client cannot compute when it is
    safe to resume. Backoff is guesswork by design.
x-evidence:
  - url: https://cernerdemo.api.us-1.healtheintent.com/allergy/v1/populations/{populationId}/patients/{patientId}/allergies?limit=1
    status: 401
    fetched: '2026-08-27'
    note: no rate-limit headers present on the response
gaps:
  - No published requests-per-second, per-minute or per-day figure for any tenant or endpoint.
  - No documented rate-limit response headers, so no runtime signal for an agent to read.
  - No documented Retry-After, so no bounded backoff.
  - No per-tier or per-endpoint differentiation is published.