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.
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.
