Open Dental API Integration: How the Vendor Ecosystem Actually Works

If you run Open Dental and you’re shopping for software — an AI scribe, an intake product, an eligibility tool — you have a real advantage: Open Dental publishes an API, publishes the list of vendors who use it, and publishes a judgment about each one. You can look a vendor up before the sales call instead of after.

The catch is that an open ecosystem also means more ways to buy something that duplicates what you already pay for, or something that touches your database in a way your malpractice carrier would not enjoy hearing about. This page is about reading the ecosystem before you sign.

Why the Open Dental ecosystem looks the way it does

Two structural reasons.

First, the database is local. That means an integration can be built against it directly, without anyone’s permission — and Open Dental’s own vendor list carries a tier for software that works that way.

Second, being listed costs nothing. Vendors contact vendor.relations@opendental.com and get reviewed. As published, 87 vendors sit in the Authorized tier, 11 in Authorized in Transition, 22 in Dangerous/Unknown, and 11 in Not Currently Active, with 14 Native Integrations listed separately.

Open Dental is not the only vendor doing this. Henry Schein One’s API Exchange also publishes its vendor list publicly, and requires the vendors on it to hold SOC 2 Type II certification and to use OAuth 2.0. That’s a different trade: a security floor you don’t have to verify yourself, versus a free listing where more of the diligence sits with you. If you’re comparing across systems, read both lists the same way.

The connection method matters more than the feature list

Open Dental’s data lives on your server. A vendor on your network can reach it directly. A cloud vendor cannot — your database is behind your firewall — so something has to relay the traffic. Open Dental’s eConnector is the piece that handles that relay; Open Dental’s own documentation and your vendor can confirm what your setup actually uses.

You don’t need to understand it in depth. You need to know two things:

• It’s a dependency. If the relay isn’t running, cloud integrations stop — not degrade, stop. When an add-on “breaks” on a Monday morning, that’s worth checking before you call the vendor.
• A vendor asking for your MySQL credentials instead of going through the API is telling you something about how they’re built.

Ask any vendor, in writing, how they connect, how access is granted, and how you revoke it. Then confirm the answer against Open Dental’s documentation rather than the vendor’s slide.

What the tiers actually mean

Open Dental sorts third-party software into tiers on a public vendor page. The labels look like a compliance formality. They are not.

Authorized means the vendor uses the official API. Reads and writes go through a supported interface that Open Dental controls and versions. When Open Dental updates, the API contract is what they maintain. This is the tier you want.

Authorized in Transition means the vendor is moving to the API but isn’t fully there. Some functions still use older methods. This is not a scarlet letter — real products take real time to migrate — but it is a question you should ask directly: which parts of your product are still not on the API, and what’s the timeline? A vendor who can answer that crisply is fine. A vendor who acts confused by the question is the answer.

Dangerous/Unknown means direct database access or unwhitelisted plugins. That does not mean the software doesn’t work — plenty of it works, and plenty of practices run it happily. It means nobody is guaranteeing what happens to your data when either side updates, and a bad write goes straight into your production tables with no API layer standing in between. If you’re already running something in this tier, you don’t need to panic; you need to know it’s there and to have a backup you’ve actually tested restoring.

Not Currently Active is its own bucket. If a product you’re being pitched turns up there, that’s a question for the sales call.

Native Integrations are listed separately from the API tiers — a different relationship, so read that label as its own thing rather than as a higher grade.

Free listing is why the list means something

Because listing is free, a vendor’s presence on the Authorized list is not paid placement. It cannot be bought. That makes it a signal that isn’t downstream of a marketing budget.

It also means absence is meaningful. If a company is selling you an Open Dental integration and isn’t on the list at all, there’s a reason, and the reason is worth five minutes of your time.

Check the $165 bundle before you buy anything

Open Dental sells its own eServices bundle at roughly $165/month. That covers Web Forms, Patient Portal, eReminders, eConfirmations, Integrated Texting, and Web Sched.

Read that list against your current vendor stack. If you’re paying separately for reminders, confirmations, or patient texting, check whether you’re already paying for them here too — and whether anyone turned the first-party version on.

The honest position: for reminders, confirmations, and basic web scheduling, the bundled tools may well be enough. Third-party products earn their price when they do something structurally different — deeper insurance work, actual clinical documentation, forms that parse an insurance card image rather than just collecting a signature. Buy the overlap only when you can name what the outside product does that the bundle doesn’t.

The AI scribe category is entirely third-party

Open Dental has no first-party AI scribe. Bola AI is a native partner, but it’s Bola’s product, not Open Dental’s. There is no in-house option coming to make this decision for you.

Which means clinical documentation is a category where you’re evaluating outside vendors on their own merits, and where the integration details matter more than the demo.

Start with accuracy, because it has actually been measured. A JMIR Medical Informatics study of 7,545 AI-generated clinical notes, 356 of which were evaluated in detail, found omissions in 18%, hallucinations in 11.5%, and accidental inclusions in 9.3%. Whatever you buy, a human still reads the note before it’s signed.

Then ask the integration question that separates people who have built on Open Dental from people who have read the docs: an Open Dental commlog has no provider field. There is nowhere structured to put “who wrote this note.” Any vendor claiming structured provider attribution on Open Dental is either wrong or writing somewhere else. The workable answer is that the provider’s name goes into the note text itself — that’s what our own Open Dental clinical notes integration does, and it’s worth hearing a competitor’s version of the same answer.

Ask about audio too, and ask feature by feature rather than product-wide, because recording behaviour can differ between a dictation tool and a consent-gated recording feature inside the same product. On our side: dictation audio is held in memory only and never written to disk, S3, or a database, and the transcript text is kept for 24 hours so an interrupted recording can be resumed or a finished dictation continued; separate opt-in, consent-gated recording features do upload audio to S3. Get the equivalent answer from any vendor per feature, in writing.

Know where the integration stops

Coverage is never total, so ask about the gaps explicitly. On Open Dental specifically, appointment status updates, appointment cancellation, and perio chart reads are outside what we do through the integration — treat them as unavailable from any vendor until one demonstrates otherwise on a live Open Dental instance. Claims submission runs outside the PMS entirely, through a clearinghouse.

So if a pitch includes “and it updates the appointment status automatically” on Open Dental, slow down and ask to see it, not a screenshot of it.

Scope also varies by system: the same product can file notes, post payments, and read treatment plans on one PMS and hit a wall on another. Ask per-PMS rather than in general — that’s how we scope our own PMS connections.

The five-minute check before you sign

1. Look up the vendor on Open Dental’s third-party list. Note the tier. Screenshot it.
2. If they’re in Transition, ask which functions aren’t on the API yet and when they will be.
3. If they’re not listed at all, ask why, and ask how they connect.
4. Compare the feature list against the eServices bundle. Circle every overlap.
5. Ask for the BAA before the trial, not after. A vendor who wants patient data flowing before paperwork is signed has told you how they operate.

None of this requires technical skill. It requires about five minutes and a willingness to ask a sales rep a question they’d rather skip.