Nirmitee.io

Healthie integration · United States

Healthie API Integration for Digital Health Products

We build on Healthie for digital health companies: headless member apps, provider tools, automations driven by webhooks and data pipelines into your warehouse. Healthie's GraphQL API is the same one its own web and mobile apps use, so the question is rarely whether the API can do it. It is how to structure keys, versions, webhooks and limits so your product stays stable as Healthie changes.

Book a scoping call ↗See what Healthie's API covers →
  • GraphQL
  • Mutations
  • Signed webhooks
  • Sandbox
  • API versioning
  • React SDKs
  • Patient encounters

Healthie is the back end. Your product is the experience.
  1. 01Get access

    The API is an add-on on Healthie's Enterprise and Group plans. Production keys are generated in Settings; sandbox access is requested from Healthie.

  2. 02Build against a version

    Pin the Healthie-GraphQL-API-Version header, use per-user keys for user-facing flows and a service key for back-end jobs.

  3. 03React to events

    Signed webhooks tell your system when appointments, forms, notes or claims change, so you query only what moved.

Evidence you can check

The problem

Sound Familiar?

Digital health teams building on Healthie tell us about these four problems first.

One shared API key for everything

Every action in Healthie shows up as the same service account, so nobody can tell from the audit log which member or clinician did what.

Webhooks you cannot trust yet

Events arrive, but nothing checks the signature, retries create duplicate jobs, and a failing endpoint is disabled before anyone notices.

Claims that changed after they were sent

Billing edits a claim after submission and the payer's copy no longer matches what your team sees.

Reporting that breaks on release day

A nightly export stops working when a field changes, because the queries were never pinned to an API version.

Use cases

What It Looks Like When It Works

Four use cases, each shown as the screen your team works in. The members and staff are fictional; the API behavior follows Healthie's published documentation.

Bookings From Your Own Member App

Today

Members book in one place, then staff re-enter or fix the appointment in Healthie.

With the integration

Members book in your app with their own API key, the appointment is created or moved in Healthie, and a taken slot or an unsupported appointment type is handled before the member is told it worked.

What we build
  • Per-user API keys so Healthie's audit log shows the real user
  • createAppointment and updateAppointment calls checked against availability and appointment types
  • API version pinned in the Healthie-GraphQL-API-Version header
Member bookings from a custom app written to Healthie, with a moved visit, a taken slot and an unsupported appointment type
Illustrative screen with fictional members: member bookings from a custom app written to Healthie, with a moved visit, a taken slot and an unsupported appointment type. Tap to open full size.

Automations Driven by Signed Webhooks

Today

Staff watch Healthie for new documents and care plan changes and copy them by hand.

With the integration

Each webhook is checked against its HMAC signature before anything runs, duplicates are ignored safely, and a call with a bad signature is rejected with nothing processed.

What we build
  • Signature verification with Content-Digest and Signature headers
  • Idempotent jobs so a retried webhook never runs twice
  • Alerts before Healthie disables a failing webhook endpoint
Webhook events from Healthie with verified signatures, a skipped duplicate and a rejected call with a bad signature
Illustrative screen with fictional members: webhook events from Healthie with verified signatures, a skipped duplicate and a rejected call with a bad signature. Tap to open full size.

Encounters and Claims That Stay Consistent

Today

Billers edit sent claims and lose track of what the payer actually received.

With the integration

Each encounter links the visit, the signed note and the CMS 1500. Sent claims stay locked, and a denied claim is fixed through a correction claim that starts in Not Sent.

What we build
  • Encounter reads that tie appointments, notes, claims and payments together
  • Claim lock respected, with createClaimCorrection for fixes
  • Unsigned notes flagged before a claim goes out
Encounters and claims from Healthie with locked sent claims, a correction claim after a denial and an unsigned note
Illustrative screen with fictional members: encounters and claims from Healthie with locked sent claims, a correction claim after a denial and an unsigned note. Tap to open full size.

A Warehouse Sync That Survives Releases

Today

A nightly export breaks after a Healthie release and nobody knows until reports look wrong.

With the integration

Sync jobs run on a pinned API version with small pages under the complexity limit, recover from rate limit errors, and pause for review when the changelog shows a field change.

What we build
  • Paginated queries pinned to an API version
  • Backoff and retry on TOO_MANY_REQUESTS errors
  • A weekly changelog review before any version upgrade
Warehouse sync jobs from Healthie with query complexity, a recovered rate limit and a job paused for a changelog review
Illustrative screen with fictional members: warehouse sync jobs from Healthie with query complexity, a recovered rate limit and a job paused for a changelog review. Tap to open full size.

First call

Questions We Will Ask You on the First Call

The answers decide how much you build headless, how keys and versions are set up and where these projects usually go wrong.

Which Healthie plan are you on, and is the API add-on active?

API access comes with the Enterprise and Group plans, and sandbox access is requested separately.

Which features stay in Healthie's interface and which move to your app?

Building everything headless is rarely needed; the split decides most of the cost.

Will your product act as each user or as one service account?

Per-user keys keep Healthie's audit trail accurate for user-facing features; a service key suits back-end jobs.

Which events should your product react to?

Each webhook needs a verified receiver, an idempotent job and an owner when it fails.

Do you bill insurance through Healthie?

Claims, encounters and claim lock add rules your product must respect.

Which API version are you on today?

Pinning a version and reviewing the changelog prevents surprise breakages.

What data must reach your warehouse, and how fresh?

Volume and freshness decide page sizes, schedules and how close you get to the limits.

Which systems outside Healthie must connect?

Hospital EHRs, eligibility checks and devices are separate integrations built beside Healthie.

The short answer

Does Healthie Have an API? Yes, One GraphQL API

Healthie offers a single GraphQL API that its own front end uses, so it covers scheduling, charting, forms, billing, insurance, chat, video and organization settings. Queries read, mutations write and subscriptions stream events. Access is an add-on on Enterprise and Group plans; production API keys are generated in the account settings and sandbox access is requested from Healthie. Keys act as the user they belong to, every request carries an Authorization header, and breaking changes ship as dated versions you opt into with a version header. Healthie sends signed webhooks for common events, with retries for up to three days if your endpoint fails. Healthie signs a BAA. What you still build is your own experience, your data model on top of Healthie's and the connections Healthie does not offer.

Who it is for
Digital health startups and virtual care companies building member apps, provider tools or analytics on Healthie.
What we build
Headless booking and intake, provider tools, webhook automations, claim and encounter workflows, and a warehouse sync with versioned queries.
The outcome we design for
A product on Healthie that keeps working through Healthie's releases, with clear ownership of keys, versions and events. These are intended outcomes, confirmed in your build.

What Healthie's API covers

What Healthie's API Lets You Read and Write

From Healthie's API documentation and help center, checked in October 2026. The API is the same one Healthie's own apps use, so most features are reachable; these are the parts that shape a build.

AreaWhat it coversWrite accessWhat to plan for
SchedulingAppointments, availability, appointment types and calendar syncCreate, update and cancel through mutationsTime zones, provider availability rules and calendar sync behavior per account
Charting and formsCharting notes, form templates, filled forms, documents, care plans and goalsCreate forms and entries; lock and sign follow Healthie's rulesWhich notes your product writes and which stay with the clinician
Patient encountersEncounters created when an appointment is marked Occurred, linking notes, the CMS 1500 and requested paymentsThrough the linked objectsHistorical encounters were backfilled for appointments since 2025; design reports around the encounter, not the appointment alone
Billing and insuranceBilling items, packages, invoices, insurance plans, CMS 1500 claims and claim submissionCreate billing items and claimsClaim Lock is an organization feature flag; submitted claims lock and corrections use a correction claim
WebhooksEvents such as appointment.created, document.created, care_plan.updated and claim_submission.updatedNot applicableVerify the HMAC signature on every call; retries run for up to three days, then the webhook is disabled
Limits and versionsDynamic request rate limits, a complexity limit of 2000 per request and a depth limit of 25Not applicablePaginate with small pages, pin an API version and read the weekly changelog
SandboxA separate staging environment with its own URL and IDsFull, with fake data onlyNo PHI in sandbox; faxing, Zoom, Withings and Change Healthcare labs are not available there; ICD and CPT codes are limited

Healthie's API is described by Healthie as closed: access comes with the plan add-on, not self-serve sign-up. Lab orders through the Change Healthcare integration run in an iframe and cannot be placed through the API, though results can be read.

What we build

What Our Healthie Integration Builds

Pick the workstreams your product needs. Each one ships with a specification, sandbox tests and an owner.

01

Headless Member App

Booking, intake forms, messaging and payments in your own web or mobile app, using per-user API keys so Healthie's audit log records the real user.

Per-user keys · appointments · forms · chat

Telehealth software development →
02

Provider Tools

Custom dashboards, care plans and charting helpers for your clinicians on top of Healthie's charting, without changing what Healthie owns.

Charting notes · care plans · goals · tasks

03

Webhook Automations

Signed webhooks verified and turned into jobs, for example sending a signed chart note to your downstream system or flagging an out-of-range metric, with idempotent handlers.

HMAC SHA-256 · Content-Digest · retries

04

Claims and Encounters

Encounters, CMS 1500 claims and claim submissions read and written in the order Healthie expects, with locked claims corrected through a correction claim.

PatientEncounter · Cms1500 · createClaimCorrection

RCM integration →
05

Warehouse and Reporting Sync

Paginated queries pinned to an API version, kept under the complexity limit, feeding your warehouse for reporting across operations, finance and outcomes.

Versioned queries · pagination · complexity

X12 EDI for developers: 270/271, 837, 835 →
06

Connections Healthie Does Not Have

EHR connections to Epic, athenahealth or other systems, eligibility checks or devices, built beside Healthie and kept in sync with its records.

FHIR · HL7 · eligibility · devices

FHIR integration services →

Buyer decisions

Ways to Build on Healthie Compared

Most products mix these. The choice per feature decides how much you build and how much Healthie's own interface does.

OptionBest fitStrengthsWhat to plan for
Healthie's interface and white labelTeams that want to launch fastLeast build; Healthie maintains the screensLess control over the member experience
Headless on the GraphQL APIProducts with their own member or provider experienceFull control of the experience on Healthie's back endYour team owns the front end, keys, versions and limits
Healthie plus authenticated iframesAdding custom views inside Healthie's web interfaceKeeps Healthie's screens and adds yoursWeb only; not supported in the mobile white label
Warehouse syncReporting, finance and outcomes analysisYour BI tools on Healthie dataVersioned queries and pagination under the complexity limit
Marketplace integrationSoftware vendors serving mutual Healthie customersHealthie customers can connect your productHealthie's marketplace process; you build with API and sandbox access

We say which features are better left to Healthie's own interface, and which are worth building.

Integration boundaries

Healthie Integration Boundaries: Who Owns What

We write the split down before the build starts.

Your organization

Owns the Healthie plan and API add-on, the API keys and which team members can manage developer features.

Healthie

Owns the API, its versions, limits, sandbox and webhooks, and supports the API with its developer support team.

Your product team

Owns your experience, your data model on top of Healthie and how features appear to members and clinicians.

The integration layer (ours)

Clients, key handling, webhook verification, retries, sync jobs, redacted operational logs and alerts. Defects in this layer are ours to fix.

Clinical decisions

Notes, care plans and orders stay the clinician's; automations route information and never sign on their behalf.

Security and PHI

Healthie signs a BAA with you. A BAA is also available from us for agreed work involving PHI, under our ISO 27001:2022 certified management system. No PHI goes into the sandbox.

Deliverables

Healthie Integration Deliverables

Everything lands in your repository and your runbook.

01

Feature map

Which features use Healthie's interface, which are headless and which are new connections, with the queries and mutations for each.

02

Integration code in your repository

GraphQL clients, key handling, webhook receivers and sync jobs, with environment settings kept out of the code.

03

Version plan

The pinned API version, how changelog entries are reviewed and how an upgrade is tested before you switch.

04

Test evidence

Sandbox runs covering happy paths, rate limit errors, webhook retries, signature failures and claim corrections.

05

Security pack

Key ownership, permissions, webhook verification and log redaction, documented for your security review.

06

Monitoring and runbook

Failure alerts, webhook health and a support runbook that includes how to raise an issue with Healthie.

Delivery phases

Healthie Integration Timeline

Initial planning estimate: 6 to 10 weeks to a first production feature set, subject to your plan's API access, sandbox provisioning and design sign-off. Discovery confirms the first features before you commit to a release date.

  1. 01

    Discovery and access

    Weeks 1 to 2

    Feature map agreed, sandbox requested, API version chosen, key model decided

  2. 02

    Build

    Weeks 2 to 6

    Clients, screens, webhooks and sync built and tested in the sandbox

  3. 03

    Production readiness

    Weeks 5 to 8

    Production keys, webhook endpoints and monitoring set up; data checked with your team

  4. 04

    Go-live and hypercare

    Weeks 7 to 10

    First users live, alerts on, runbook handed over, next features scheduled

Cost drivers

What Drives Healthie Integration Cost

Use the scoping call to pin down the workflow, the access you need and what goes into a scoped proposal. These are the factors that move cost.

How much is headless

Each feature built in your own front end adds screens, states and tests.

Webhook automations

Each event your product reacts to needs a verified receiver and an idempotent job.

Billing and claims

Claims, encounters and payments add rules and test cases.

Outside connections

EHR, eligibility or device connections beside Healthie are separate integrations.

Reporting depth

Warehouse models across many objects take more query design.

Support level

Monitoring and on-call support are priced per connection.

Book a call ↗

Proof

Engineering Work You Can Check

Client names are withheld. These published guides show how we approach API and EHR work; they do not prove Healthie approval or a live customer integration.

Published engineering guide

EHR Automation Without API Access

How we decide between APIs, RPA and computer-use agents when a system's API stops short, and the controls each needs.

Read the guide →

Published engineering guide

Multi-EHR API Comparison

How Epic, Oracle Health, athenahealth and eClinicalWorks expose their APIs, useful when your Healthie product must also reach a hospital EHR.

Read the guide →

Published engineering guide

HIPAA Compliant AI Scribe

The consent, review, access and retention controls we build into clinical AI features, which apply to notes your product writes.

Read the guide →

Security

ISO 27001:2022 Certified, BAAs Signed

We are ISO 27001:2022 certified and sign Business Associate Agreements for work that touches patient data.

FAQ

Healthie Integration: Questions Buyers Ask

Does Healthie have an API?

Yes. Healthie offers a GraphQL API, the same one its own web and mobile apps use, with queries, mutations and subscriptions. Healthie describes it as a closed API: access comes as an add-on on its Enterprise and Group plans.

Is the Healthie API REST or GraphQL?

GraphQL. Requests are HTTP calls to a single GraphQL endpoint, so any HTTP client works, though Healthie recommends a GraphQL client such as Apollo Client and its API Explorer for testing queries.

How do I get a Healthie API key?

Users with API access generate production keys under Settings, Developer, API Key, and admins can give team members permission to manage developer features. Sandbox keys are requested from Healthie. Each key acts as the user it belongs to.

Should we use one service key or a key per user?

Healthie supports both. A service key fits back-end and data jobs. For user-facing features, Healthie recommends a key per user so its audit logging, notifications and defaults behave as they do in its own apps.

Does Healthie have webhooks?

Yes. Healthie sends an HTTP POST with the resource ID, type and event for events such as appointments, documents, care plans and claim submissions. Payloads are signed with HMAC SHA-256, and optional retries run for up to three days before the webhook is disabled.

What are Healthie's API rate limits?

Request rate limits are dynamic and return a TOO_MANY_REQUESTS error when exceeded. Each request also has a complexity limit of 2000 and a depth limit of 25, so we paginate with small pages and keep queries narrow.

How does Healthie API versioning work?

Breaking changes ship as dated versions that you opt into with the Healthie-GraphQL-API-Version header, while non-breaking additions appear in every version. We pin a version and test upgrades against the weekly changelog.

Can we build a headless app on Healthie?

Yes. Healthie supports fully headless use through the API, using parts of its interface beside your own, and authenticated iframes on the web. We usually build the member experience headless and keep administrative work in Healthie.

What is not available in the Healthie sandbox?

The sandbox is separate from production with different IDs and no PHI allowed. Faxing, Zoom, Withings and Change Healthcare labs are not available there, and ICD and CPT codes are limited, so we plan those tests in production with care.

Can Healthie connect to Epic or other EHRs?

Not through Healthie's API alone. Connections to hospital EHRs, eligibility checks or devices are separate integrations that we build beside Healthie and keep in sync with its records, using FHIR, HL7 or vendor APIs.

How long does a Healthie integration take?

Our initial planning estimate is 6 to 10 weeks to a first production feature set, subject to API access on your plan, sandbox provisioning and design sign-off. Later features reuse the clients and tests.

How much does a Healthie integration cost?

Cost depends on how much you build headless, the webhook automations, billing and claims scope, outside connections, reporting depth and support level. After a scoping call we send a scoped proposal with the access dependencies listed.

Next step

Plan Your Healthie Build

Tell us what your product does on Healthie today and what you want to build. An engineer replies with the feature map, the key and version plan and the open questions.

Book a call ↗Send your Healthie details →

Start with your workflow

Tell Us About Your Healthie Integration

Share the features, your plan's API access and your target date. Use de-identified examples only. Read by an engineer, answered within one business day.

Please exclude patient data and credentials. We use these details to respond to your inquiry. Privacy policy

Thank you. Your inquiry has been received. Our team will review your requirements.

Standards and Primary Sources