Healthcare is the apis.io vertical where API shape is most directly dictated by regulation. Most providers in this cohort don’t get to design their API from scratch — they have to publish a FHIR-conformant surface for clinical data, a HEDIS / payer-specific surface for benefits and eligibility, and a HIPAA-compliant transport for everything. The catalog reflects that, and walking it teaches you the shape of US healthcare integration in 2026.
The functional bands
Healthcare on apis.io organizes into:
| Band | Examples on apis.io |
|---|---|
| Clinical / EHR (FHIR-anchored) | Epic, Cerner, Athenahealth, MEDITECH, Healthie, Redox |
| Payer / claims / eligibility | Elevance Health, UnitedHealth (Optum), Humana, Centene, Change Healthcare |
| Pharmacy / Rx | Surescripts, GoodRx, Capsule, Photon |
| Life sciences / pharma | Veeva, IQVIA, Medidata, OpenFDA |
| Wearables / consumer health | Polar, Withings, Garmin, Apple HealthKit, Oura |
| Health-tech infra | Particle Health, Health Gorilla, 1upHealth, Datavant, Constellation |
Most production stacks in this vertical end up combining at least one row-1 EHR connector, one row-2 payer surface, and one row-6 infra layer. The integration cost of the combination is real and is the reason the Health Gorillas, Redoxes, Particles, and 1upHealths of the world exist as a category in their own right.
FHIR is the substrate
A real shift in the last two years: FHIR has gone from “regulatory compliance burden” to “default integration substrate”. Epic, Cerner, Athena, and every major EHR now publish FHIR R4 endpoints as their primary external surface. The apis.io entries for these EHRs are anchored on FHIR resources — Patient, Observation, Condition, Medication, Encounter, etc. — as the canonical capability set.
This makes the catalog more useful than it would otherwise be, because FHIR-conformance creates cross-vendor capability comparability that no other regulated vertical has. The capability “fetch patient observations” looks essentially the same across Epic, Cerner, and Athena in the catalog. That’s rare and worth recognising.
What’s shifted recently
Three patterns from the last six months:
- TEFCA QHINs are coming online. Datavant, Health Gorilla, eHealth Exchange, Epic, and several others are now operating as Qualified Health Information Networks under the federal Trusted Exchange Framework. The catalog is starting to track which providers expose QHIN-mediated APIs versus direct integrations.
- Payer APIs are catching up to clinical APIs. CMS Interoperability and Patient Access Rule has forced payers to publish Patient Access and Provider Directory APIs. Elevance, UnitedHealth, Humana, and others are all now in the catalog with real machine-readable surfaces — a category that was largely absent five years ago.
- AI-on-FHIR is emerging. The vector-database providers (Pinecone, Weaviate) are showing up in healthcare RAG architectures alongside FHIR-conformant clinical sources. The catalog can express this composition by linking FHIR-resource capabilities to vector-search capabilities at the workflow level.
Where to start
- Healthcare-related providers — the canonical filtered list (when present).
- Provider profiles worth walking: Epic, Veeva, Elevance Health, Redox.
- Capability layer — searching for FHIR resource verbs (
fetch patient,search observations,submit eligibility request) gives the cleanest cross-vendor view.
The takeaway
Healthcare is the vertical where API standardisation is happening under regulatory pressure rather than via market consensus, and that’s actually been good for catalogability. FHIR is the single best example in any apis.io vertical of cross-vendor capability comparability, and the payer-API cohort is starting to follow.
If your work touches clinical, claims, or life-sciences data, the apis.io network is one of the few places you can compare the actual machine-readable surface of these providers side by side. The marketing language across this cohort is famously interchangeable; the API shapes are not, and that’s where the real selection criteria live.