Halaxy API: what you can and can't build with it

Quick answer: Halaxy’s free tier is one of the lowest entry-cost ways into a cloud PMS in Australia — the platform is free, with revenue coming from card-processing fees — which is exactly why so many solo allied-health practitioners run on it. The API covers the core entities: clients and appointments are well-covered, billing data is accessible, webhook events cover a subset of changes, and a handful of modules aren’t exposed programmatically. For solo and small practices, the patterns below are enough to build the missing layer. Once a practice scales past a few clinicians with complex shared scheduling, in our experience the gaps usually become the prompt to consider migration.

Halaxy started as a cloud-based practice management product for Australian allied-health practitioners and grew on the back of an unusual commercial model: the platform is free, revenue comes from processing fees on patient card payments. For a solo physio, OT, psychologist or podiatrist starting out, that’s a near-irresistible entry point. It also means Halaxy now has a broad user base in the Australian allied-health PMS market. In our experience working alongside it, the patterns where practices reach for custom work are around API breadth and multi-practitioner scheduling complexity — areas where Cliniko and Nookal are often the alternative platforms considered.

Integration work falls into three areas: extended patient-facing experiences, multi-clinician scheduling logic with non-trivial constraints, and reporting deeper than the native dashboards. Four patterns cover most of what we build for allied-health practices on Halaxy.

What the Halaxy API actually exposes

Concretely, what’s accessible:

• Read access to patients, appointments, providers, invoices and a subset of clinical metadata
• Constrained write access — create patients and appointments, update certain demographic fields, post invoice line items
• Webhook coverage on a subset of events — some events emit; for the events that aren’t covered, most integrations end up polling on a schedule
• No clinical-note write access — clinical text stays inside the consult workflow, as it should

That last point matches what you’d find on most clinical software (same shape as the Best Practice API piece): clinical content is read-only from outside, and the integrations work on the practice-management layer rather than the clinical layer.

Pattern 1 — Branded patient portal on Halaxy data

Halaxy has built-in patient-facing features (the public directory and booking widget). They’re functional by design and don’t carry the practice’s brand the way a custom flow can. For practices that have invested in a brand, in our experience the gap shows up immediately: the website looks great, then the booking flow drops the patient into a standard Halaxy surface.

What it takes to close this:

• A patient-facing portal at your domain that reads the patient’s upcoming and past appointments from Halaxy
• Self-service rescheduling with the constraints the practice actually uses (don’t allow rebooking within 24 hours; only allow same-type swaps; etc.)
• Account and invoice history pulled from Halaxy with the practice’s branding wrapped around it
• A messaging path back to the practice for non-clinical questions, with the conversation filed against the patient record

Same shape as any clinical PMS — the platform is the source of truth for what happened, the portal is the patient-facing surface that interprets it.

Pattern 2 — Custom intake forms that feed clinical records

Halaxy’s built-in intake forms cover the basics; the branching logic and validation rules most multi-discipline practices want sit outside what they’re designed to express. In our experience, new-patient intake then becomes either a friction point in the booking flow or a separate process that reception manually transcribes.

The integration:

• A custom intake form on the practice website with the conditional logic the practice actually uses
• Validation appropriate to each discipline (different intake for physio vs psychology vs paediatric)
• On submission, a Halaxy patient record is created or matched, with the structured intake fields mapped to demographic and clinical-flag fields
• Free-text intake content lands as a clinical note attached to the patient’s record, ready for the practitioner to read before the first consult
• Identity matching against existing patients (email + DOB + Medicare number) so re-attending patients don’t create duplicates

The practice gets a first-consult that starts with the practitioner actually informed about the patient — rather than fifteen minutes of intake-during-consult that nobody enjoyed.

Pattern 3 — Accounting reconciliation that doesn’t lose half a day a fortnight

Halaxy handles invoicing; Xero (or MYOB) holds the books. Reconciliation between them ranges from “mostly OK” for small practices to “painful and error-prone” once volume picks up.

The integration:

• Daily import of invoiced services from Halaxy into Xero, with line items preserving service category and clinician attribution
• Card-payment receipt matching where the Halaxy-processed payment ties back to a specific invoice
• Medicare and DVA bulk-bill reconciliation when the rebate arrives, with shortfalls flagged for follow-up
• Provider payment splits calculated from Halaxy billing data when the practice runs multiple practitioners on different commission structures

The mistake to avoid: making Halaxy the source of truth for accounting. Halaxy owns what was done and what was billed. Xero owns what was paid. The integration syncs the first into the second — not the other way.

Pattern 4 — Multi-clinician scheduling logic above what the built-in scheduler covers

Halaxy’s scheduling works fine for solo and very-small-team practices. In our experience, the constraints that appear once a practice runs 3-4 clinicians across overlapping rooms with discipline-specific availability rules are where practices start reaching for a custom layer on top of the built-in scheduler:

• Provider A only sees new patients on Tuesdays and Thursdays; provider B doesn’t do telehealth before 10am; provider C only works in rooms 2 or 4 because the equipment is there
• Group-pricing for partner appointments where two clinicians share a session
• Recurring appointment series with mid-series rule changes
• Insurance-funded appointment caps that need to halt new bookings once reached

For practices that have a few of these rules, the pattern we typically build is a separate online booking surface on the practice website that applies the constraints in code and writes the resulting bookings back to Halaxy — same approach as we’d use for EzyVet’s booking surface when the practice’s operational reality sits above what the native widget covers.

Once the rules get genuinely tangled, in our experience it’s often the prompt to look at moving to Nookal or Cliniko — practices that have made that move often comment on the multi-practitioner scheduling fit.

When custom isn’t the answer

Three cases where Halaxy out-of-the-box is the right call:

• Solo practitioner, low patient volume, no team plans. The free tier plus the built-in features is more than enough; build nothing.
• Practice already planning a Cliniko or Nookal migration. Don’t invest in custom Halaxy work that’ll be thrown away in six months.
• Practice with no operational lead. Custom integration needs a known person to notice when it breaks. Without that, you’re adding a fragile dependency.

The threshold where Halaxy integration work earns its place is roughly 2-3 clinicians, an operations lead in the practice, and a clear answer to whether the practice intends to stay on Halaxy or migrate within the next year.

What a typical engagement looks like

Halaxy projects start with a half-day audit: where the practice is typing data twice, which patient-facing flows are losing patients to friction, which reports the practice owner wants and can’t get. The plan stages the highest-friction items first (usually the patient portal and intake forms), then accounting reconciliation, then any scheduling work that’s genuinely workable within Halaxy’s constraints.

Running Halaxy across an allied-health practice and weighing whether to invest in custom work or migrate to Cliniko or Nookal? That’s the conversation worth having before the build.