athenahealth · Rate Limits

Athena Health Rate Limits

Name: Athena Health Rate Limits
Creator: athenahealth
Keywords: EHR, Electronic Health Records, Healthcare, HL7, FHIR, Interoperability, Practice Management, Revenue Cycle Management, USCDI, Cures Act, SMART on FHIR, CDS Hooks, Cloud EHR

Rate limit policies for athenahealth's API surface. athenahealth applies per-application throttles. Specific quantitative limits are disclosed to registered developers in the portal and may vary by environment, tablespace, and product. The values below are typical for athenaOne integrations; refer to the athenahealth Developer Portal for authoritative limits for your app.

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

The profile also includes 5 backoff/retry policies defined.

Tagged areas include EHR, Electronic Health Records, Healthcare, HL7, and FHIR.

0 Limits

EHRElectronic Health RecordsHealthcareHL7FHIRInteroperabilityPractice ManagementRevenue Cycle ManagementUSCDICures ActSMART on FHIRCDS HooksCloud EHR

Policies

The athenaOne proprietary REST API enforces per-application throttles against each tablespace (production or preview). Typical default is in the range of ~10 requests/sec sustained per app per tablespace; exact limit is disclosed to the developer.

The FHIR R4 endpoints share the same throttling tier as the proprietary REST surface. SMART Backend Services tokens are scoped to system-level reads and follow the same per-app quotas.

The athenahealth Event Subscription Platform delivers notifications via rest-hook. Subscriber webhooks MUST acknowledge with a 2xx response within a 2-second timeout. Delivery failures are retried with backoff; persistent failures move the subscription into error status.

Bulk Data Access ($export) is asynchronous. Concurrent job limits are enforced per application; clients SHOULD respect the Retry-After header returned with 202 responses and SHOULD NOT poll status more frequently than once per minute.

OAuth 2.0 token endpoints are subject to anti-abuse throttling. Clients SHOULD cache access tokens for their full TTL and avoid token churn.