For dental technology products
We build Open Dental API integrations for dental technology products: booking and confirmations, patient and recall sync, forms and documents, payments and claims status, and read-only reporting. We also run the access path with you, from the developer key to activation in each office. For a wider view of dental practice management APIs, read our dental practice management API guide.
Plan my Open Dental integrationFor dental software companies, DSOs and AI voice, scheduling and patient communication products selling into Open Dental offices. Updated September 2026.
The problem
What dental technology teams tell us when they start building on Open Dental.
One request per second on paid tiers, and one every 5 seconds on the free read tier, makes large syncs crawl.
Remote calls reach the office through its eConnector, so a stopped eConnector looks like an API outage.
Read, write and Enterprise tiers are priced per location, and the wrong tier blocks a feature.
Without webhooks, products poll appointments and patients all day and still miss changes.
Use cases
Four use cases, each shown as the screen your team works in. The offices and patients are fictional; the Open Dental rules behind each screen are real.
Patients are offered times that are already taken.
Open time comes from the Appointments Slots endpoint by provider or operatory, and appointments are created, confirmed or broken through the API.
An office is activated and calls fail because of an old version or a stopped eConnector.
Each office's version, eConnector and hosting are checked first, and the API mode and permission tier are chosen from that.
A busy office floods the API, gets 429s and drops requests.
Requests queue per office at the allowed rate, back off on 429 with Retry-After, and move to Local or API Service mode where volume needs it.
Reminders go out with the old appointment time.
Subscriptions send webhooks when appointments, patients or schedules change, and PatientSelected shows call notes the moment the front desk opens a patient.
Booking
Open Dental publishes its API, so each action maps to a documented call. Open Dental calls a cancelled or missed visit a "broken" appointment.
| Action | Open Dental API |
|---|---|
| Find open times | Yes. The Appointments Slots endpoint returns open times by provider or operatory. |
| Book a new appointment | Yes, including planned and Web Sched appointments. |
| Confirm | Yes. The API sets the confirmation status. |
| Reschedule | We break the old appointment, create the new one and read both back. We do not rely on a single move call. |
| Cancel | Yes. The API breaks the appointment. |
Each office enables your developer key with its own customer key before any of this works. Vendor terms change, so we recheck every action in the program before a release.
First call
The answers decide the API mode, the permission tier and the rollout.
Each maps to specific API resources and a permission tier.
Remote needs version 21.1 or later; Local and API Service need newer versions.
We check each Cloud office before choosing the mode.
High volume points to Local mode, the API Service or Queries to SFTP.
Open Dental approves keys in one to three business days, and the key belongs to your company.
Marking a claim sent records it in Open Dental; the electronic submission still runs through the clearinghouse.
Subscriptions replace most polling.
Remote calls depend on it, so monitoring and ownership are agreed up front.
What we build
Open Dental calls its REST API the approved method of writing to its database. Everything below runs through that API, never through direct database writes, which Open Dental flags as dangerous.
Open time comes from the Appointments Slots endpoint, which reads open schedule times by provider or operatory. We create appointments, planned and Web Sched appointments, confirm or break them and add notes. Schedules and operatories are read only, so the office keeps control of the calendar itself.
Patients, recalls, providers and communication logs can be read, created and updated, so a call, text or form your product handles lands in the patient's record. For large databases we use the lighter Patients Simple read and page through results with Limit and Offset.
Sheets are created from the office's own sheet definitions, and documents and images are uploaded by base64, from a URL or through SFTP. Downloads of documents, forms as PDF and large query results are delivered to an SFTP site you control.
Payments, partial payments and refunds post through the API, and claims can be created, split and marked sent. Marking a claim sent records an Etrans entry in Open Dental; the electronic submission itself still runs through the office's clearinghouse, which we connect separately over X12 837D and 835.
Subscriptions send webhooks when appointments, patients, providers, schedules or operatories change, at a polling frequency you choose, and a PatientSelected event fires instantly on chosen workstations. For analytics we run read-only SQL through the Queries endpoint.
Three API modes
Calls go to api.opendental.com and reach the office through its eConnector. This is the route most products start on, and it is throttled by permission tier.
The Local API runs on a workstation while Open Dental is open (version 22.1+). The API Service runs continuously, usually on the database server (version 22.2+). Neither is throttled.
From developer key to production
Open Dental approves developer keys in one to three business days, so the calendar is set by office activation and version checks rather than by access.
We prepare the request to Open Dental with you: company details, the API resources your product needs and an app description. The key belongs to your company.
A developer key and a resource list tied to each feature.Open Dental hosts a test database for developers. We build and test every workflow there first, including throttling, paging and error handling.
Tested workflows and a permission tier that matches them.We confirm the office's Open Dental version, eConnector health and whether it runs Open Dental Cloud, then choose Remote, Local or Service mode.
A readiness check per office.You create the customer key in the developer portal, the office enables it under Setup, Advanced Setup, API, and we monitor calls, 429s and eConnector uptime.
A repeatable activation runbook and support handover.Evidence
The engineering behind our Open Dental delivery, with public code you can inspect.
Our open-source clearinghouse simulator covers 270/271, 837, 999/277CA and 835, the transactions a dental billing product runs next to the Open Dental API.
Clearinghouse simulator on GitHub ↗18 public healthcare repositories on GitHub, including our headless EHR and X12 tooling, so you can read how we build before you hire us.
Nirmitee on GitHub ↗Our team has built 350+ interfaces on Mirth Connect, the engine we use when an Open Dental office also needs HL7 to a lab or medical EHR.
Before you commit
Yes. Open Dental has a REST API that it describes as the approved method of writing to its database. It runs in three modes: Remote through api.opendental.com, Local on a workstation, and as an always-on API Service on the office network.
Open Dental prices API access per location per month. Reading everything is free, and write tiers are $15, $30 and $35, with prices unchanged since September 2020. An Enterprise tier from version 23.3 raises limits. Charges start when the office enables the key and stop when it is disabled.
Email Open Dental vendor relations with your company, contact and billing details, the API resources you need and a description of your app. Open Dental says requests take one to three business days. We prepare the request with you so the resource list matches your features.
You create a customer key for the office in the Open Dental developer portal. The office then adds it in Open Dental under Setup, Advanced Setup, API, and can enable or disable it at any time.
Yes. The Appointments Slots endpoint returns open schedule times by provider or operatory, and the API can create, confirm and break appointments, including Web Sched appointments. Schedules and operatories themselves are read only.
Usually the throttle. The Remote API allows one request per second on paid tiers and one every 5 seconds on the free read tier, with 100 items per page. We queue calls per office, use webhooks instead of polling, and move bulk work to Local or Service mode or Queries to SFTP.
Open Dental says many API vendors are available to Open Dental Cloud offices, while products that install a separate program may not be compatible. We check each Cloud office before choosing the mode.
Read-only SQL is common, and the API's Queries endpoint runs screened read-only queries without database access. Writing to the database directly is the pattern Open Dental flags as dangerous, so every write we build goes through the API.
The number of workflows, which permission tier they need, whether offices can run Local or Service mode, their Open Dental versions and how many offices you activate. Open Dental's API fees are separate from our engineering fees.
Define the next step
Tell us about your product and the offices you sell to. We will come back with the API mode, permission tier and activation steps your workflow needs.
Please don’t include patient data, credentials or sensitive records.
Open Dental is a trademark of Open Dental Software, Inc. Other product names are trademarks of their respective owners.
