Open Dental API Integrations: What Actually Works in Production

Open Dental is genuinely open—source code included—which makes it unusually hackable for a practice management system. That openness is also why so many integration projects start confidently and stall six weeks in. The surface area is large, the documentation is uneven, and the gap between a working demo and a production-grade connector is wider than most teams expect.

Here is what we have learned building and maintaining Open Dental integrations across multi-location DSOs, solo practices, and specialty groups.

Two Integration Paths: MySQL Direct vs. the REST API

Open Dental gives you two primary routes. The first is direct MySQL access—the database schema is documented and relatively stable. The second is the Open Dental REST API, introduced in version 21.1 and expanded steadily since.

Direct MySQL reads are fast and flexible. They are also a liability. Schema columns get renamed or repurposed on minor version bumps. Triggers and stored procedures you did not write can fire unexpectedly. If your integration writes directly to the database without going through the application layer, you will eventually corrupt a record in a way that is hard to trace and harder to explain to a dentist whose schedule just disappeared.

Our rule: read from MySQL when the REST API does not expose what you need; write exclusively through the API or the Open Dental service layer. It is slower to build, but it survives upgrades.

The Appointment and Patient Objects Are Deceptively Complex

The two objects every integration touches first are Patient and Appointment. Both look simple in the docs. Both have sharp edges.

• Patient deduplication is not handled for you. If your intake form creates a new patient record and the front desk already added one manually, you now have two. Build a match-before-create check using DOB plus last name plus a phonetic fallback before any write operation.
• Appointment status codes are a flat integer enum, but their meaning shifts depending on whether the practice uses the Confirmation feature. A status of 2 means something different in a practice that auto-confirms versus one that does not. Parameterize this per-client.
• Provider assignment on appointments is separate from the treating provider on procedures. Reporting integrations that pull revenue by provider get this wrong constantly. Always join through the procedurelog table, not the appointment header.

Webhook Gaps and the Polling Reality

Open Dental does not have a native outbound webhook system as of the current stable release. If you need near-real-time event propagation—appointment booked, patient checked in, claim submitted—you are polling. That means designing a reliable change-data-capture layer on top of MySQL, typically watching timestamp columns like DateTStamp on the tables you care about.

A few things make this less painful in practice:

• Run your polling service inside the practice's network or VPN, not over the Open Dental API from the cloud. Latency and connection limits matter at scale.
• Use a watermark table in a sidecar database to track the last-processed timestamp per entity type. Do not rely on the source table alone—you will miss updates during downtime windows.
• For DSOs with 10-plus locations, fan-out polling across sites with a message queue (SQS, RabbitMQ) before your processing layer. Polling 15 MySQL instances synchronously from a single service is a reliability problem waiting to happen.

VoiceChart and the Charting Data Model

Periodontal charting data in Open Dental lives in the perioexam and periomeasure tables. The structure is normalized but verbose—a single full-mouth perio exam generates over 160 individual measure rows. When we built VoiceChart, our voice-driven charting layer, the write path had to be transactional across all those rows or the exam would appear partially complete in the Open Dental UI.

Batch inserts inside a single transaction, validate the exam record exists before writing measures, and always delete-then-reinsert on correction rather than updating individual measure rows. The UI re-renders from scratch on exam load anyway, so partial updates create confusing visual artifacts.

Version Drift Is the Silent Project Killer

Practices update Open Dental on their own schedules. A DSO client might have locations running 23.1, 23.3, and 24.1 simultaneously. Your integration needs a version negotiation step at connection time—query the preference table for the ProgramVersion value, store it, and gate feature flags accordingly. Anything else leads to support calls you cannot reproduce in your test environment.

Practical Takeaway

Before you write a single line of integration code, document the exact Open Dental version range you will support, map every write operation to an API endpoint or service-layer call (never raw SQL), and build version detection in from day one. The practices that get the most out of Open Dental's openness are the ones that treat the application layer as a contract—not the database schema.

If you are scoping an Open Dental integration or hitting a wall on an existing one, talk to the Romanov Solutions team. We have seen most of the failure modes already.