OpenDental integrations:
a practical guide.

The fastest way to ruin a clinic demo is to forget about integration. Voice agents, patient apps, scheduling tools — all of them die at the moment they need to read or write the clinic's actual schedule. And in dental specifically, that schedule lives inside OpenDental or Dentrix, neither of which ships the clean REST API you'd hope for.

This guide is the version we'd have wanted before we started. It covers what integration actually looks like in production for both platforms — and the gotchas that aren't in any sales deck.

1. The honest landscape

Modern dental apps generally need to do four things against the PMS:

1. Read patient records (name, contact info, insurance, history)
2. Read schedule availability across providers and operatories
3. Write new appointments and modify existing ones
4. Read clinical context relevant to messaging (recall due, treatment plan)

OpenDental and Dentrix both support these — they just don't make it obvious how.

2. OpenDental — the realistic integration path

The API exists. Sort of.

OpenDental offers the Open Dental API, available through their OpenDentalCloud service or as a Web API alongside an on-prem install. It's REST-shaped, but the surface area is narrower than what most developers expect from a "modern API."

Practical realities:

• You need to coordinate with the clinic's IT to enable API access and generate developer + customer keys
• Rate limits are conservative — design for backoff and batching
• Not every PMS workflow has a clean endpoint; some operations require compound calls or fall back to direct DB access patterns the clinic approves
• Schema evolves between versions — wrap your access in a thin adapter you control

The data-pipe pattern that actually works

For SmileLink we settled on this shape:

1. A sync worker per clinic, running on a schedule (typically every 60–300 seconds) and on demand
2. The worker pulls deltas — appointments, patients, recall — into our HIPAA-aligned warehouse
3. Reads serve from the warehouse for speed; writes go through a queue that serializes into the PMS to avoid race conditions
4. A reconciliation pass catches any drift between warehouse and PMS

The warehouse model is the single biggest unlock. Reading the PMS live for every patient-facing surface will not scale and will not give you the speed you need for a good mobile experience.

3. Dentrix — the bridge approach

Dentrix is the older sibling. There's a Dentrix Developer Program (DDP) and an xCharge / API stack, but in practice many integrations still land on a local bridge running on a clinic workstation. The bridge connects to the Dentrix database and exposes a controlled API to your cloud.

What the bridge needs to do

• Run as a service on a clinic-controlled machine that's always on
• Authenticate to your cloud over an outbound, mutually-authenticated tunnel (the clinic firewall won't allow inbound)
• Surface a stable, versioned API even as Dentrix versions change underneath
• Handle the office being offline gracefully — queue writes, retry on reconnect
• Be observable: heartbeats, error reporting, version reporting

The gotchas

• Locks. Dentrix tables can be locked by the front-desk client during write operations. Plan for retry-with-backoff on every write
• Soft deletes. Records are flagged as deleted, not removed. Your sync needs to honor flags, not assume row absence means deletion
• Time zones. Local clinic time vs. UTC vs. patient time — pick one canonical layer and convert at the edges
• Provider mapping. Provider IDs change when staff rotates. Your app's references need a stable indirection layer

4. Patterns that work across both

The adapter pattern, not the abstraction pattern

Tempting move: write a "universal PMS interface" and have each integration implement it. Reality: OpenDental and Dentrix differ enough in semantics that a shared interface either over-generalizes (and loses fidelity) or balloons. We recommend adapters per PMS that produce a normalized data shape, with PMS-specific logic kept in the adapter.

Idempotent writes, always

Every write operation should carry an idempotency key. Retries are inevitable — you don't want to create the same 9 a.m. cleaning four times because your worker restarted.

Capacity windows over single slots

Don't model availability as a list of bookable slots. Model it as capacity windows by provider and appointment type. Your booking logic decides slot resolution at request time, which lets the same capacity model serve a voice agent, a patient app, and a marketing reactivation flow.

HIPAA on the wire

• All traffic between bridge and cloud over mutual TLS
• BAAs with cloud + database + observability vendors
• PHI fields encrypted at rest, separate from operational metadata
• Audit logs of every read and write, append-only storage

5. What to budget

Realistic timelines from start to first paying clinic:

• OpenDental first integration: 4–8 weeks engineering for a production-grade, HIPAA-aligned sync + write path
• Dentrix bridge first integration: 6–10 weeks, mostly because of the bridge deployment + clinic-side ops
• Each additional clinic: days, not weeks, if you've architected for multi-tenancy from day one

The economics work because the second, tenth, and hundredth clinic don't re-cost the integration — you've already paid for the platform.

6. Where Leyoxa fits

We've shipped both OpenDental and Dentrix integrations in production — across the DDS Marketing AI suite and SmileLink. The pattern above is what we run.

If you're building a dental product and you don't want to spend six months on the integration layer before you can talk to a clinic, book a 30-minute discovery call. We co-build with operators who have distribution and conviction.