[ HEALTHIE INTEGRATION ]
Healthie is provider-facing — it gives new patients no real self-serve way to discover, choose a plan, pay, and onboard. So practices duct-tape that layer out of n8n, Zapier, and Claude Code, and it breaks at scale. We build the deliberate version: one owned codebase that wraps the Healthie GraphQL API, owns the patient-facing surfaces, and enforces payment-gating. Healthie stays your system of record.
30 min with a co-founder. No sales pitch.
GraphQL
Healthie API
HIPAA
architecture
4–6 wk
per phase
[ THE PROBLEM ]
Healthie is the system of record for clinical, billing, and prescribing state. But it is built for providers, not for the patient who hasn't signed up yet. The gap between "stranger on your homepage" and "activated Healthie patient" is yours to build — and most practices fill it with no-code glue that quietly rots.
01
02
03
[ WHAT WE BUILD ]
One owned codebase: discovery → plan → pay → onboard. It wraps the Healthie GraphQL API, replaces the no-code sprawl, and enforces payment-gating. Healthie stays the system of record.
The #1 revenue fix. Soft-hold the slot → charge through Healthie billing → create the appointment only on confirmed payment. No payment, no appointment. Idempotent, so a retried webhook never double-books.
A typed GraphQL client, a signed webhook receiver that re-fetches the full record by ID, per-provider API keys so the right clinician is each patient's primary provider, retry and escalation on every call, and an append-only audit log.
Service selection, multi-state provider matching against each provider's licensed states, and a clean refer-out path when there's no licensed match. The pre-login acquisition surface only — once activated, patients live in the native Healthie portal.
Collapse 30+ n8n workflows into one typed, tested, observable codebase. Version-controlled, secrets in one place, no monthly execution ceiling, no silent webhook death. The glue stops being load-bearing duct-tape.
Appointment reminders and SMS flows driven off Healthie webhooks, plus a daily webhook health-check cron that probes every subscription and alerts the moment one silently disables — before it breaks onboarding for days.
Provider-to-patient matching on licensed states, and the foundations for insurance/billing — eligibility and claims via a clearinghouse when a practice bills insurance rather than running cash-pay only. Built into the funnel, not bolted on later.
[ PAYMENT-GATING ]
The single most common revenue leak on Healthie is appointments that exist without a paid charge. The fix is an ordering decision, and there is only one correct ordering.
Create the appointment, then charge. When the card fails you're left with a confirmed slot and an empty till. Wrong.
Charge and create at the same time, or run a separate Stripe charge. Double-charge risk, and it breaks Healthie's chart of accounts. Wrong.
Hold the slot, charge through Healthie billing, create the appointment only on confirmed payment. Idempotent and concurrency-safe, so a retried webhook never double-books or double-charges. Card data never leaves Healthie — never a parallel Stripe charge.
[ PLATFORM BEHAVIOR ]
General Healthie platform behavior that bites teams in production. We've done the homework on each one — and architect to neutralize it from day one.
01
Whoever's API key creates the appointment becomes the patient's primary provider — use the org-admin key and the admin silently becomes everyone's clinician. Fix: mint per-provider API keys and authenticate as the target provider.
02
Tags are wired to billing — applying a tag fires a package charge, so bulk tag automation can silently bill people. Fix: never use tags for routing or metadata; use appointment types, custom fields, or chart notes.
03
The payload is just an ID and changed fields — never the full state — and an *.updated event doesn't mean the operation succeeded. Fix: re-fetch the full record by ID and verify state before acting.
04
After repeated delivery failures a webhook flips to disabled — no alert — and onboarding silently stops while nobody notices. Fix: a daily health-check cron that probes every subscription and alerts on any disabled or warned hook.
05
Every status transition arrives as a generic appointment.updated, so you can't tell a cancellation from a no-show from the event type. Fix: inspect changed_fields and the re-fetched status to branch correctly.
06
Some list-as-string fields need a trailing comma even for one ID: "85543" is a silent no-op; "85543," works. Fix: know the quirk and handle it in the typed client, not by trial and error in prod.
[ PROCESS ]
Rebuild slice-first. The first commit is small and shippable, never a six-figure big-bang. We start with the slice that fixes the biggest revenue leak, ship it, measure on real numbers, and decide the next phase from there.
A spike on your Healthie staging environment confirms the API surface, the webhook model, and the billing path before we commit to scope. This is how we de-risk having no shipped Healthie project yet.
The payment-gated booking funnel plus the integration layer and webhook health-check foundations. 4-6 weeks. The slice that fixes the biggest revenue leak first.
Ship phase one, watch the real numbers, then decide the next phase — onboarding, SMS, multi-state, billing — on evidence rather than a guess made up front. 4-6 weeks per phase.
[ WHAT WE'VE SHIPPED ]
We haven't shipped a Healthie project yet — we'll always say so. What we have shipped is the exact discipline a Healthie build needs: regulated-healthcare delivery, idempotent billing, and vertical-SaaS API integration.
~8 weeks
DEA Compliance Platform
Regulated healthcare with an immutable, append-only audit trail. Took a broken MVP to production in roughly eight weeks. The same correctness bar a patient-facing EHR layer demands.
Idempotent
Fintech Compliance MVP
An idempotent billing and payment-correctness backbone — exactly the discipline a payment gate needs. Charge once, never double, safe under retries and concurrency.
Open source
Clio + MyCase MCP Connectors
Two open-source connectors that integrate vertical-SaaS APIs in depth — OAuth, typed clients, audit logging, rate limiting. Proof we go deep on a platform's API, not just shallow glue.
Healthie expertise, honestly: deep platform research, adjacent regulated-and-payment proof, and a Week-1 integration spike on your staging before we commit to scope. We never invent a track record we don't have.
[ RELATED READING ]
The architecture behind the build, plus our compliance and AI-privacy thinking for healthcare.
Headless EHR Guide
What it actually takes to build the patient side
The integration layer, payment-gating, and the Healthie footguns nobody documents — the full companion to this page.
HIPAA + AI
HIPAA-compliant AI in healthcare software
The architecture that keeps PHI safe when AI is in the loop — BAAs, audit trails, and data boundaries.
Zero Data Retention
Claude Team vs API for sensitive data
Which Claude tier actually gives you zero data retention, and what that means for regulated workloads.
[ FAQ ]
A headless EHR is an electronic health record where the clinical data, billing, and logic live in one API-driven system, and the patient-facing experience is built separately on top of that API.
Most telemedicine practices do not buy a headless EHR. They run a standard EHR like Healthie and build their own patient-facing surfaces against its GraphQL API — which makes the architecture headless whether or not it was a deliberate decision. Read the full breakdown.
Yes. Healthie is API-first and designed to sit behind a custom front end. The practice owns the patient-facing surfaces — discovery, plan selection, booking, payment, onboarding — and Healthie remains the system of record for clinical data, billing, and prescribing.
The work lives in the integration layer: a typed GraphQL client, a signed webhook receiver that re-fetches by ID, payment-gating, and an audit log.
No-code automation works well for gluing two systems together for a while. It breaks down when the glue becomes load-bearing: webhooks silently disable, there are no tests, secrets are scattered across dozens of workflows, monthly execution limits stall everything during an error storm, and the same logic is duplicated where nobody tracks it.
A single owned codebase replaces 30+ workflows with something typed, tested, observable, and safe to change.
Neither create-then-charge nor a parallel charge is safe. Create-then-charge leaves you with confirmed appointments nobody paid for when the card fails. A parallel Stripe charge double-charges and breaks Healthie's chart of accounts.
The correct ordering is soft-hold the slot → charge through Healthie billing → create the appointment only on confirmed payment, with idempotency so a retried webhook cannot double-book or double-charge. The charge runs through Healthie's billing mutations — never a separate Stripe charge.
We have not shipped a Healthie project yet, and we will say so plainly. What we have done is study Healthie's GraphQL integration surface in depth — the webhook model that carries only IDs, the billing-via-tags behavior, the per-provider API key footgun, the silent trailing-comma no-op.
We de-risk every engagement with a Week-1 integration spike on your Healthie staging environment before committing to scope. Pair that platform homework with our track record on regulated-healthcare builds and payment-correctness systems, and you get a team that knows exactly where the platform bites.
Simple integrations and automations start from $1,700. Custom builds — a payment-gated booking funnel, a typed integration layer, a patient onboarding experience — run $17K to $53K, delivered in phases so the first commit is small rather than a six-figure big-bang.
The exact number depends on how many patient-facing surfaces you need, how much no-code sprawl we are replacing, and the depth of billing and multi-state logic involved. Book a call and we will scope it honestly.
We phase the work, typically 4-6 weeks per phase. Phase one is usually the payment-gated booking funnel plus the integration and webhook-health foundations — the slice that fixes the biggest revenue leak. We ship it, measure on real numbers, and decide the next phase from there rather than scoping the whole thing up front.
Yes. Healthie remains the system of record for clinical data, billing, prescribing, and the signed-in patient portal. We do not rebuild the native portal.
The owned codebase we build sits in front of Healthie: it owns the pre-login acquisition and onboarding funnel, wraps the GraphQL API, and orchestrates payment-gating and reconciliation. Once a patient activates their Healthie account, they live in the native portal.
A typed GraphQL client against api.gethealthie.com, a signed webhook receiver that treats every payload as an ID-only notification and re-fetches the full record before acting, per-provider API keys so the right clinician is set as each patient's primary provider, retry and escalation paths on every external call, an append-only audit log, and a daily webhook health-check cron that alerts when a subscription silently disables.
It is the part that no-code tools cannot do safely.
Yes, as foundations we build into the onboarding and booking flow. Provider state licensure lives on the Healthie user record, so we match patients to providers licensed in their state and refer out cleanly when there is no match.
For insurance, Healthie does not run eligibility or claims natively — that is a separate clearinghouse integration (X12 270/271 eligibility, 837P claims, 835 ERA) we can architect when a practice bills insurance rather than running cash-pay only.
[ GET STARTED ]
30 minutes with a co-founder. We'll map your Healthie surfaces, find the biggest revenue leak, and tell you honestly what phase one should be.
Accepting 1 new healthcare build
