Integrate With Athenahealth.
The free Certified FHIR APIs vs the proprietary AthenaOne APIs, 2-legged and 3-legged OAuth, SMART on FHIR, and the back-end-only, per-customer access model that makes Athenahealth different — mapped by engineers who ship it.
Athenahealth Is One Cloud — With Two API Lanes and One Big Rule
Athenahealth's AthenaOne is a single-instance, multi-tenant cloud (EHR + practice management + revenue cycle). Unlike Epic and Cerner — where each customer runs its own instance — every Athenahealth practice lives in one shared platform, addressed by a Practice ID. That shapes everything about how you integrate.
Two decisions define your build. First, which API lane: the Certified APIs (FHIR R4 / US Core, ONC-certified, free to AthenaOne Base customers) or the proprietary, fee-based AthenaOne APIs (athena's internal data model, /v1/{practiceid}/…, gated by a Platform Services contract + BAA). Second, the access rule that catches everyone: Athenahealth only ever grants third parties back-end access, per customer — you get into a client's live data after that organization signs its own Authorization & Consent (A&C) form, and it can revoke it any time.
$export with _since incremental deltas (which Epic doesn't offer), and CDS Hooks. Get the lane and the access model right, and Athenahealth is a clean build.Three Ways to Integrate — Pick the Right One
The free FHIR lane, the proprietary paid lane, and the app-launch surface. Each has a different cost, auth, and use case.
Certified APIs (FHIR)
Athenahealth's FHIR R4 / US Core APIs, ONC-certified under the 21st Century Cures Act — (g)(7) patient selection, (g)(9) all-data, and (g)(10) Standardized API. The standard, interoperable way to read clinical data.
What You Get
US Core / USCDI clinical data — Patient, Observation, Condition, MedicationRequest, DocumentReference and the rest — plus Bulk Data $export with _since.
Auth & Base
OAuth 2.0 (2-legged or 3-legged) at /oauth2/v1/token; FHIR base /fhir/r4. Same base is (g)(10)-certified for SMART on FHIR.
Going to Production
Apps using only Certified APIs have a self-service production onboarding path — no proprietary contract needed for the API itself.
Best For
Standard clinical reads, patient access (PHR), interoperability, and population pulls where US Core covers your needs.
AthenaOne APIs (Proprietary)
Athena's original REST APIs — data shaped exactly how AthenaOne organizes it internally, with endpoints like /v1/{practiceid}/…. This is where the deep practice-management and revenue-cycle workflows live, beyond what US Core exposes.
What You Get
Athena's proprietary data model — scheduling, billing/RCM, and clinical workflows not covered by the Certified FHIR set. Not FHIR.
Auth & Base
OAuth 2.0, endpoints scoped by {practiceid}. Same Preview/Production token endpoints, different resource surface.
Going to Production
Requires a signed Athenahealth Platform Services contract plus a BAA — this is the "non-Certified" lane, and it's a commercial relationship, not a self-serve toggle.
Best For
Deep, athena-specific workflows — practice management, scheduling, and revenue-cycle automation.
SMART on FHIR & CDS Hooks
The app-launch and in-workflow surfaces layered on the Certified FHIR APIs — how your app runs inside athenaClinicals or as a patient app.
SMART on FHIR
Both Patient Standalone and Provider EHR launch sequences (FHIR R4, (g)(10)-certified) — available since v22.7 (July 2022). Provider 3-legged also extends to DSTU2.
CDS Hooks
Built on CDS Hooks 2.0 — but only the order-select hook is supported (it fires when a clinician creates an order). patient-view is not supported.
Auth
3-legged OAuth (authorization_code) via /oauth2/v1/authorize → /token, with the user consenting to your scopes.
Best For
Provider-facing in-EHR apps, patient (MyChart-style) apps, and order-time clinical guidance.
Verified July 2026 against Athenahealth developer docs (docs.athenahealth.com) + the Athena Core FHIR IG. Some items (HL7 v2, TEFCA/QHIN status, exact fees) weren't in the public docs — we confirm per engagement.
Back-End Only, and Per-Customer
Athenahealth protects PHI by never giving partners front-end production access — and by making every customer opt in individually. Here's the real path.
Register (Developer Console)
Create an account and a Preview app; receive client credentials for the sandbox.
Build in Preview
Develop & test against non-sensitive dummy data. Preview creds work only in Preview.▲ separate creds
Choose Your Lane
Certified-only → self-service prod. AthenaOne → Platform Services contract + BAA.▲ contract if non-certified
Per-Customer A&C
Each mutual customer (by Practice ID) signs an Authorization & Consent form — per customer, revocable.▲ per customer
Back-End Access
You're granted back-end access to that client's Production tablespace. No front-end prod access, ever.
Because access is per-customer, the win is a repeatable A&C + onboarding process so customer #10 is a quick form, not a project. On network access: Athenahealth's technical requirements can restrict to US-based IPs and vary by setup — we confirm the current requirements (and any allow-listing / VPN) for your environment rather than assume.
Certified APIs vs AthenaOne APIs
The single most consequential — and least-explained — choice in an Athenahealth build. Pick the lane that matches your data needs.
/fhir/r4/v1/{practiceid}/…Many products use both — Certified FHIR for standard clinical reads, AthenaOne for the athena-specific workflows FHIR doesn't cover. We help you use the free lane wherever it's enough, and only pay for the proprietary lane where you actually need it.
If You Know the Big Two, Here's What's Different
Same FHIR spine, three very different operating models.
_sinceBuilding for more than one? A shared US Core layer covers most reads. See our Epic, Oracle Health, and all-EHR guides.
Where Athenahealth Builds Go Wrong
The mistakes we're most often called in to fix.
Athenahealth grants partners back-end production access only. Design for server-to-server / API access, not an in-app production login.
The Authorization & Consent form is per customer (by Practice ID) and revocable — build a repeatable process, one per org.
The proprietary lane means a contract + BAA. Use the free Certified FHIR lane wherever US Core covers the data you need.
Tokens last one hour; new-token requests are rate-limited (50/min prod, 5/min preview). Cache the token or you'll hit the limit.
Athenahealth Integration, Answered
The questions teams ask before they start.
What's the Difference Between the Certified APIs and AthenaOne APIs?
/v1/{practiceid}/…) that expose deep practice-management and revenue-cycle workflows in Athena's own data model — they're fee-based and require a Platform Services contract + BAA. Most products use the free FHIR lane wherever it's enough and the paid lane only where needed.Is Athenahealth Integration Free?
How Do I Get an Athenahealth Sandbox and Go to Production?
What Is the Authorization & Consent (A&C) Form?
Does Athenahealth Support SMART on FHIR, Bulk Data and CDS Hooks?
$export with the _since incremental filter — so you can pull only what changed (Epic doesn't offer this). CDS Hooks is on the 2.0 spec, but currently only the order-select hook is supported (patient-view is not).Do I Need a VPN or Special Network Access for Athenahealth?
More on EHR Integration
Epic Integration, End to End →
The largest EHR — ecosystem, programs, SMART, and the vendor journey.
Oracle Health (Cerner) →
Millennium, Code Console, SMART STU1, and the per-tenant model.
EHR Integration Across Vendors →
Epic, Oracle Health, Athenahealth, MEDITECH and more, compared.
Skip the Guesswork — Get Your Path Mapped.
Tell us what you're building and which Athenahealth customers you're targeting. We'll send back a specific plan: which API lane, the OAuth flow, the sandbox-to-production and A&C steps, and a realistic timeline.
Thanks — We've Got It.
Your Athenahealth Integration Plan is on the way, within one business day.