Open Dental API integration: what is published, what is gated, and what to ask

Start with what your vendor already publishes

A dental group looking at a CRM or a patient-communication tool reaches the same question every time. What can another system read and write in the practice-management software we run, and what does that access cost?

Sales calls answer in general words. Some vendors answer in writing, with figures, on a public page. We read what several practice-management vendors publish, on 19 September 2026. Some was open. Much sat behind an agreement. Here is what each document said that day.

Open Dental publishes the clearest material

How access is granted

The Open Dental API Developer Setup page, read on 19 September 2026, says a developer requests Developer Portal access from vendor relations by email and submits company and billing details, a description of the application, and "a list of the API resources you need access to and for each permission, whether you need read, create, or update". The same page says "Requests take one to three business days to process."

It describes two keys. A Developer API Key is "unique to each developer and is obtained by logging into the Developer Portal". A Customer API Key is "unique to each customer/developer pair and generated by the developer within the portal". So the software vendor holds one key, each office gets its own under it, and a key can be switched off per office.

What access costs, and the unit it is charged in

The Open Dental API Permissions page, read on 19 September 2026, publishes what it calls general monthly pricing for the API: free for Read All at a throttle of one request per five seconds, $15 for the Comm, Documents, InsuranceSimple, Setup and Queries permissions at one request per second, $30 for all permissions except Payments, PayPlans and Special, and $35 for all except Special. The same page states "Pricing is per location", and says a key must be assigned and enabled before charges apply and that billing stops when the key is disabled.

The unit is the location, so whatever tier an integration needs, that figure repeats for every office you turn on. Read access is priced and throttled separately from write access. Watch the page titles: Open Dental's API Fees page, read the same day, documents fee schedules inside the software.

What the specification and the vendor list say

The Open Dental API Specification page, read on 19 September 2026, lists resources across patients, appointments, claims, procedures, insurance and payments, with GET, POST, PUT and DELETE methods per resource. It states that "If a field is not included in a PUT (update), then it will not change the original field in the database". That line decides how a sync behaves when two systems hold the same field. The page also says "API developers should have a Business Associate Agreement (BAA) in place with their clients".

The Open Dental Third-Party Vendors page, read the same day, says "The Open Dental API is the approved method of writing to the database (such as creating an appointment or entering a payment)", and treats writing to the database outside the API as a risk to the office. It says "We only list vendors who have an available product with a verified API status", and adds "We do not necessarily recommend any of these companies, nor do we provide technical support for their products or services." Ask which method a product uses.

What the other vendors published on the same day

Some publish the detail where anyone can read it. Others publish that a program exists and keep the rest behind an agreement. That difference is no measure of product quality. It tells you how long an answer takes.

Dentrix and Dentrix Ascend

The Henry Schein One API Exchange page, read on 19 September 2026, covers Dentrix and Dentrix Ascend, describes OAuth 2.0, asks vendors to apply for membership, and publishes no charges. The Dentrix Developer Portal FAQ, read the same day, does. For Dentrix it states "a one-time registration and set-up fee ($5,000 READ, $5,000 WRITE) and a monthly royalty fee based on API categories selected". For Dentrix Ascend the same page, read on 19 September 2026, states a one-time $5,000 registration and set-up fee, "A monthly $47 fee for each Dentrix Ascend Location, which includes 30K calls and 3GB data per location/per month", and overage at "$0.0018/call and $1.00/GB data". An agreement is signed before a key is issued, and the endpoint documentation arrives with membership, so we did not read it.

Eaglesoft, Denticon, Curve Dental and connector platforms

Patterson's support article on API information for Patterson Innovation Connection vendors, read on 19 September 2026, is scoped to vendor and support audiences. It names the documents it holds, including API fields and methods, and says the API applies to Eaglesoft version 18 and above. We could not open those documents, and no charges were published there.

On 19 September 2026 the Planet DDS developer portal for Denticon listed API categories by name, including patient, appointments, revenue cycle management and clinical resources. The endpoint pages returned no readable content to us, so the endpoint list, the access process and any charges stay gated and unverified. The Planet DDS integrations page, read the same day, publishes no access process and no figures.

The Curve Dental integration partner page, read the same day, lists partners and contact details. We found no developer documentation or fee schedule there.

NexHealth's developer documentation was readable without an account on 19 September 2026, and says developers "integrate with dozens of health record systems using a single universal API". A connector platform adds a third party to the chain, so the questions below apply to it too.

What to ask your own vendor, in writing

• Which API do you offer, and where can we read the documentation before signing anything?
• What does access cost, and is the charge per location, per practice, per call or per developer?
• Do read and write cost differently, and which permissions does our use case need?
• What are the rate limits, and what happens to our data when they are hit?
• Who receives the invoice, and who at our group can switch a key off?
• What agreements are expected between us, the software vendor and any integrator?
• Does this integration use the published API, and what is your position on other methods?
• If we add three locations next year, what changes on the invoice?

Ask by email. A vendor who answers in writing has told you something about the next two years.

Where we stand, and what our bias is

This is our first dental work, and we say so on the first call. We build the workflow layer beside these systems: where an inquiry came from, which location owns it, who has the next action, and what happened at the end. The chart, the schedule and the ledger stay in the practice-management system.

Our bias is easy to state. We make a living building custom software, so treat any argument we make for building as coming from people who benefit from it. For most groups, configuring what you already own is the cheaper first move. The figures above cut both ways for us, because a per-location API charge is paid by whoever integrates, ourselves included.

We have no partnership, reseller arrangement or affiliation with Open Dental, Henry Schein One, Patterson, Planet DDS, Curve Dental or NexHealth, and nothing here is endorsed by any of them. We make no compliance claim of our own about the software we build. Data handling, a business associate agreement and each system's access rules get settled in writing before any build touches real records.

What we could not verify

Published terms change. Every figure above is what a named page said on the date given, so open that page yourself before you budget from it. We did not read the gated documentation for Dentrix, Eaglesoft or Denticon, so we say nothing about what those APIs support. Where we found nothing published, that is a statement about one public page on one day.

To decide which parts of a workflow should connect at all, our companion guide on what stays in a dental CRM and what stays in the PMS is the worksheet we use first.

Discuss a group workflow