Health Gorilla · Rate Limits

Health Gorilla Rate Limits

Health Gorilla applies per-client rate limits to its FHIR R4 API. As a FHIR server, search responses are paginated (via _count and Bundle next links) and large federated record retrievals are returned asynchronously (202 Accepted with status polling) rather than in a single response. Specific request-per-second / per-minute limits are not publicly documented and are governed by each client's onboarding agreement; values are not reconciled in this artifact.

Health Gorilla Rate Limits is the machine-readable rate-limit profile for Health Gorilla on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring requests, results, and jobs.

The profile also includes 2 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Health, Interoperability, FHIR, Clinical Data, and Lab Ordering.

3 Limits Throttle: 429
HealthInteroperabilityFHIRClinical DataLab OrderingRate LimitingQuotasThrottling

Limits

API Requests client
requests
see provider documentation
Per-client request throttling governed by the onboarding agreement.
Search Page Size request
results
see provider documentation
Controlled by the FHIR _count parameter; paginate via Bundle next links.
Federated Retrieval client
jobs
asynchronous
Large person-authorized retrievals return 202 Accepted and are polled for completed / partial / failed status rather than rate-limited inline.

Policies

Asynchronous Retrieval
Long-running federated queries are processed asynchronously; clients poll a status endpoint instead of holding a single synchronous request open.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor Retry-After on 429 responses.

Sources