For software vendors and medical groups connecting tools to athenaOne. We explain how the platform is laid out for developers, which of its two API families to call, how to hear about changes, and how we deliver scheduling, intake, documents, billing, analytics and AI integrations. Xcodefix is independent of athenahealth and holds no partnership with it.
athenahealth runs athenaOne as a single-instance, multi-tenant cloud, so nothing is installed at the practice. Instead, proprietary calls name the practice in the path, as in /v1/{practiceid}/departments. Credentials are issued per environment: Preview keys reach only the Preview host and Production keys only Production. New developer accounts can call a shared Preview sandbox practice, 195900, populated with dummy data.
athenahealth cites more than 800 API endpoints on its Developer Portal, split between proprietary athenaOne APIs and FHIR R4 APIs certified to the 21st Century Cures Act (g)(10) criterion. Change notification is in transition too: established changed-data subscriptions that you poll, and a newer Event Subscription Platform that pushes FHIR Subscription notifications to your webhook, which athenahealth's own repository describes as a limited alpha.
Get those two choices right and most of the build is ordinary API engineering. Our FHIR and HL7 engineers settle them at design time, before any code is written.
| Aspect | athenaOne proprietary APIs | Certified FHIR R4 APIs |
|---|---|---|
| Base path | api.platform.athenahealth.com/v1/{practiceid}/ | api.platform.athenahealth.com/fhir/r4 |
| Coverage | Workflow groups: appointments, charts, documents, encounters, insurance and financial, practice configuration | USCDI data profiled by US Core, as the federal criterion defines |
| Writing data | Read and write, from booking appointments to recording payments | Certification requires reads; check the reference for any write you need |
| App launch | OAuth 2.0 credentials issued per environment | Certified SMART launch: patient standalone and provider EHR launch |
| Portability | Specific to athenahealth | Standard FHIR, reusable across certified EHRs |
| Best for | Operational workflows and write-back | Patient access apps and standard clinical reads |
Many products use both: FHIR for standard clinical reads that also work against Epic and other certified EHRs, and proprietary endpoints for athenaOne workflows that FHIR does not reach.
Register, create an app and store the secret, which is displayed once. The Console's analytics tab reports call volume, errors, practices live on your app, and rate-limit usage per second and per hour.
A separately hosted test environment with dummy data, including sandbox practice 195900. Build and break things here; Preview credentials cannot touch Production.
Live practice data under HIPAA, reached with separate Production credentials and addressed one practice ID at a time.
athenahealth's app store, listing 590+ partners as of June 2025. Partners get a Marketplace page, co-branded marketing material and a dedicated Partner Success Manager.
HL7 and C-CDA interfaces, with custom interfaces on request, plus Data View, a SQL-queryable data store for analytics and bulk extraction that can feed a warehouse or BI tool.
Rate-limit usage is shown per app in the Console, so design against your own numbers there rather than figures quoted elsewhere.
For record types that offer it, imaging results among them, you subscribe once through a /changed/subscription endpoint, to every event by default or to a named one, optionally per department. You then poll the matching /changed endpoint for new changes. A leaveunprocessed flag lets you test without consuming them.
Near real-time notifications built largely on the FHIR Subscriptions R5 Backport guide: rest-hook delivery, id-only payloads, and topics such as Patient.create and Appointment.check-in. You create one subscription per topic per practice, and athenahealth's API team grants the scopes.
Your endpoint must use HTTPS with a publicly trusted certificate on port 443 and should verify each message signature. Keep the handler thin: acknowledge, queue, then call back for the full resource.
Confirm event availability for your practices before designing around it, and keep a polling fallback for anything the platform does not yet publish.
Show open slots and book appointments from your own site or app through the appointments workflow APIs.
Match or create patients, capture demographics and insurance before the visit, and react to Patient.create and check-in events.
Send documents to the chart and follow changes to clinical documents and imaging results through the change feeds.
Show balances and record patient payments taken outside athenaOne, using the payments and insurance and financial APIs.
Data View for SQL-level extraction into a warehouse, with FHIR or proprietary reads where fresher data matters.
Read appointment and chart context before the visit, then return the draft note or call summary through the documents APIs for clinician review, triggered by events such as check-in.
For the AI pieces, our AI and machine learning team builds the language components with access controls and data security designed in, and our guide to a HIPAA-compliant chatbot covers the safeguards for patient-facing assistants.
Each user action mapped to endpoints, fields and practice settings, choosing FHIR or proprietary per call.
Development and automated tests against Preview, starting with sandbox practice 195900, reusing access tokens until they expire rather than requesting one per call.
Polling intervals, event topics and replay handling sized against your rate limits, so a backlog never pushes the app over them.
Decide whether you will sell through the Marketplace program or serve named practices directly, and confirm Production access terms with athenahealth for that route.
Production credentials issued, practices brought live one at a time, and per-practice traffic watched in the Console through the first weeks.
Alerts for failed calls, expired credentials and missed events, with fixes shipped through the same Preview-first path.
Timelines: access approvals and each practice's readiness usually set the pace more than the code does, so we list those dependencies at the start.
Scheduling, intake, documents and billing integrations on athenaOne APIs, with error handling and monitoring from day one.
Apps on the certified FHIR R4 APIs using patient standalone or provider EHR launch.
athenahealth is among the EHRs our Mirth Connect team supports for HL7 v2 exchange.
Note drafting, summarization and assistant features from our AI team, or your existing scribe or voice vendor, connected to athenaOne workflows.
Testing your app and webhook endpoint the way an attacker would, through our penetration testing service, before the first practice goes live.
If our work touches PHI, we can sign a BAA. We have no partnership with athenahealth and do not present one; access comes through athenahealth's published programs and the practices you serve.
Send the workflow, the data involved and whether you serve one group or many practices. We will reply with the API family for each call, a change-detection design and a delivery plan.
Prefer email? info@xcodefixglobal.com
Talk to the specialist who would scope the work — not a call-centre script.
Ask us directlyIt is connecting your software to athenaOne, athenahealth's cloud platform for EHR, billing and practice management, and patient engagement, through its APIs. Most projects use proprietary athenaOne endpoints for workflows such as scheduling and payments, the certified FHIR R4 APIs for standard clinical data, and sometimes HL7 interfaces or Data View for bulk and analytics work.
Yes. athenahealth offers FHIR R4 APIs certified to the 21st Century Cures Act (g)(10) criterion, at api.platform.athenahealth.com/fhir/r4 in Production with a matching Preview host for testing. Both the patient standalone and provider EHR SMART App Launch flows were certified. Workflows outside the certified data set use the proprietary athenaOne APIs instead.
Register on the athenahealth Developer Portal and create an app to receive Preview credentials, which work against the shared sandbox practice 195900. Production credentials are issued separately and only work against Production. Vendors planning to sell to many athenaOne practices should also look at the Marketplace Partner Program, which covers listing and promotion.
Preview is athenahealth's separately hosted test environment, populated with dummy data instead of real patient records. Developers build and test there before Production, and credentials are environment-specific, so Preview keys cannot reach live data. New accounts can call the global sandbox practice, 195900, straight away from the browser or from Postman.
A practice ID, which athenahealth also calls a context ID, identifies the athenaOne practice you are working with, and most proprietary API paths include it, for example /v1/{practiceid}/departments. An app serving several practices calls each with its own ID, and event subscriptions are created per practice too. The Preview sandbox practice is 195900.
Yes, through its Event Subscription Platform, which sends FHIR Subscription notifications to an HTTPS webhook on port 443. Payloads carry resource IDs only, so your service calls back for the details. athenahealth's documentation describes the platform as a limited alpha with scopes granted by its API team, and changed-data polling remains the established alternative.
athenahealth shows each app's rate-limit usage, per second and per hour, in the Developer Console's analytics dashboard alongside call volume and errors. Read your app's limits there rather than trusting figures quoted online, reuse access tokens until they expire, and spread polling evenly instead of sending bursts that trip the per-second ceiling.
Yes, through the same APIs as any other app. A typical design reads appointment and chart context before the visit, then sends the draft note or call summary back for clinician review, triggered by events such as check-in. Recordings and transcripts contain PHI, so every speech or language vendor in the chain needs a BAA.
