OpenDental API and integrations: what actually connects

The Open Dental API is the interface Open Dental publishes so that other software can read from and write to a practice's database without touching the tables directly. An add-on asks for resources such as patients, appointments, recalls, procedures and commlogs, and every request carries two keys, one for the vendor and one for your office. Your office turns its key on, can see what it is allowed to do, and can turn it off. Open Dental calls the API the approved way for a third party to write into your data, so it is the thing to ask about when a vendor says they "integrate with Open Dental," a phrase that covers several arrangements, not all of them the API.

This is the evaluation piece, not the setup guide; once a vendor is chosen, the implementation guide takes over from the moment you hold a customer key. It is for an owner or operations lead evaluating an add-on who wants to know what "connects to Open Dental" would mean for their data, their staff, and their exit if the vendor disappoints. Everything below about the API comes from Open Dental's own documentation, linked as we go, and it applies the same way to a single office and to a group.

What is the Open Dental API?

Open Dental's API specification lists resources that map roughly one to one onto the tables in the practice database: Patients, Appointments, Recalls, ProcedureLogs, TreatPlans, Commlogs, Claims, InsPlans, and about a hundred others. Software can read those resources, create rows, update them and, for some, delete them. Open Dental's position is that changes made through the API cannot corrupt the database the way direct writes can, because the API runs Open Dental's own code and makes the audit trail entries a raw write would skip. The same page says API developers should have a Business Associate Agreement with each client office.

There are three ways an add-on can reach the API. Remote is the mode Open Dental recommends for internet-based applications: the request goes to Open Dental's servers, which validate the keys and pass it to your office through the eConnector, the service already running on your server for eServices. The API Service runs on your own server and answers requests from inside your network. The Local API runs on a single workstation while Open Dental is open. API Events can also push changes to certain tables, appointments and patients among them, to a vendor on a set interval.

"Integrates with Open Dental" can mean four things

Open Dental keeps a page on integration types that draws a line a vendor may not. Reading data does not require Open Dental's approval; a dashboard that queries your database directly is common and, in their words, generally safe, though they warn that such a tool should be easy to switch off completely. Writing is different. The API is the approved way to write. Plug-ins have been phased out. Writing straight into the tables is listed as dangerous and unsupported, partly because the office can no longer tell a row a vendor changed from a row a bad actor changed. So the first question is not "do you integrate" but "do you write, and if so, through the API or around it."

How is access granted, and who can turn it off?

The mechanics are on Open Dental's API setup page. Every request carries two keys. The developer key belongs to the vendor and identifies their application. The customer key is unique to the pairing of that vendor and your office; the vendor generates it in Open Dental's developer portal and hands it to you. Someone at your office pastes it into Setup, then Advanced Setup, then API, and checks Enabled. That window shows each key's permissions and lets you enable or disable it. You can view a key's permissions but not change them; they are set on the vendor's side.

The second thing to know: to get a developer key at all, a vendor sends Open Dental a description of the application and a list of the resources it needs, stating for each whether it needs read, create or update. So a vendor already has, in writing, the answer to "exactly what do you touch." Ask for it.

One practical note. Remote access depends on your eConnector running, so a stopped eConnector stops the vendor along with your eServices, and Open Dental alerts you when that happens. Open Dental's permissions page adds that it bills the vendor per location and by permission tier, and that billing stops when a key is disabled.

A key you can switch off yourself, with a written list of what it touches, is the difference between an integration and a dependency.

What can an integration read and write?

The permissions page is the map, organized around a distinction worth adopting in every vendor conversation. Read All is a single permission covering every read method in the API: patients, appointments, recalls, procedures, claims, all of it. It is the free tier and it is throttled. Write access is split into separate permissions by weight. Comm covers the light writes an outreach tool needs: a commlog entry, an appended appointment note, a confirmation status, a recall status. Appointments covers creating and moving appointments. Patients covers creating and editing patient records. Insurance, Payments, PayPlans and ProcedureLogs each cover heavier writes.

Two lines on that page deserve reading aloud to a vendor. First, Open Dental's normal user permissions are used to log API actions but do not restrict what the API can change. The key's permissions are the boundary, so ask what they are, not what the vendor "usually" does. Second, a Queries permission lets a vendor run its own SQL against your database. Open Dental screens those queries to be read-only and records the command in the audit trail, but a vendor holding Queries can read anything in the database, not only the resources it named.

Below is the surface most operator add-ons actually touch: what a tool typically reads there, what it might write, and the question that settles it.

Notice how much sits on the read side. A ranked call list, a production dashboard, an unscheduled treatment report, remaining-benefits math: all reads, the free tier. The writes an outreach tool needs are narrow: a commlog entry so the call shows in the chart, perhaps a recall status. Anything beyond that should come with a reason you understand.

What should you ask a vendor before connecting?

Put these in the contract, not only the demo. Open Dental's integration page says customers are responsible for contracts that specify what data is accessed or written, and for what purpose.

• Which resources and endpoints. Ask for the list they submitted to Open Dental, resource by resource.
• Read or write, for each one. Which permission groups are on the key, and why each write is necessary.
• Through the API or around it. Any write that bypasses the API is one Open Dental calls dangerous and will not support.
• Where the data lives. Whose cloud, whether your office shares an instance with other customers, and how long it is kept after you leave.
• Who else can see it. Their staff, their subprocessors, other customers in a shared pool, and the BAA that covers each.
• How access is removed. Confirm it is a customer key you disable yourself in Setup, Advanced Setup, API, and ask what they delete once it is off.
• What happens on an outage. Theirs: does anything queue and write later, and would your staff notice? Yours: what the tool does when the eConnector is down.

Does any of this change on Open Dental Cloud?

Open Dental Cloud is Open Dental's own hosted version, currently in limited release for US offices. Its product page lists, among the reasons Cloud may not fit a practice, relying on third-party integrations that do not use the API. The API modes page confirms it: Cloud customers can use the API Service, and a vendor's software does not need to know whether you are on Cloud or a local server. If Cloud is in your plans, an add-on that works through the API comes with you; one that reads the database directly may not.

What does MyDentalForce read and write?

Our own answers, in the same terms. On the read side, MyDentalForce reads recall, unscheduled treatment and lapsed patients from your Open Dental to build the ranked daily list for each office that Patient Outreach works. It is the same population your office could pull by hand from the Recall List and the Treatment Finder, ranked and per office. On the write side, MyDentalForce writes outreach outcomes back to the Open Dental commlog, so work done in MyDentalForce shows up in the chart. It also detects booked and completed appointments in Open Dental to attribute booked and produced value; every dollar in Outreach ROI ties to an appointment and to procedure rows in your own Open Dental.

On where the data lives and who sees it: each customer runs on its own isolated instance, not a shared pool, and access is invite-only, as described on the Roles, Security and Controls page. The FAQ answer on practice management systems covers what we connect to today. Bring the rest of the list to a walkthrough.

None of this requires you to understand REST. It requires you to ask for a list the vendor already wrote, to know where the off switch is, and to be suspicious of any write you cannot explain to your own front desk. If you are evaluating outreach tools, see how Patient Outreach answers the list above, and hold us to the same standard you hold everyone else.