Your product needs the patients, appointments, treatment plans and claims that live inside Open Dental, and the practice cannot re-key them. Agnotic Technologies builds the Open Dental API integration for you: scoped on a call, shipped as a fixed first release, and run with HIPAA safeguards and audit logging from the first sprint.
Trusted by global innovators
Open Dental integration connects your software to the Open Dental practice management system so patient, appointment, treatment plan, procedure and claims data move between the two without re-keying. Agnotic Technologies builds it as a services engagement, using the Open Dental REST API first and the documented MySQL database where reporting needs it, with HIPAA safeguards designed in.
Open Dental is used by solo practices, group practices and DSOs, and its API and database tables are documented publicly. That makes it one of the more open dental platforms to integrate with, but the practice still owns the data and the API permissions.
The work that decides success is not the HTTP calls. It is mapping Open Dental's procedure codes, insurance plans and appointment statuses onto your product's model, and keeping the two in step when the practice edits a record.
From the practice side: the schedule and treatment plan stay in Open Dental, while your product reads appointments, writes recall and reminder outcomes, and watches each dental claim from treatment plan to 837D submission.
Open Dental API
The Open Dental REST API exposes the practice database as named resources. These are the ones most integrations read or write.
| Code | Name | Typical use |
|---|---|---|
| Patients | Patient demographics and status | Match and create patient records, keep contact details in step with your product. |
| Appointments | Scheduled, broken and completed visits | Read the schedule by operatory and provider, write confirmations and arrival status. |
| ProcedureLogs | Treatment planned and completed procedures | Pull treatment plans and completed work by CDT code for estimates, reminders and reporting. |
| Claims | Dental insurance claims and their status | Track each claim from created to sent to received, and reconcile against the 837D and ERA. |
| InsPlans / InsSubs | Insurance plans and subscribers | Read coverage for eligibility checks and treatment estimates. |
| Recalls | Hygiene and exam recall due dates | Drive recall and reminder outreach from the practice's own recall rules. |
| Documents | Attached images and files | Link radiographs and intraoral photos to the right patient and visit. |
| Providers / Operatories | Providers, schedules and rooms | Build availability for online scheduling without double-booking a chair. |
Reference architecture
Most Open Dental integrations use two paths. The API for anything that writes or runs in real time, and a read-only database path for reporting that the API does not cover well.
Decision table
The right path depends on what your product does with the data. This is how we decide on a scoping call.
| Your need | Open Dental API | Direct database read | Our default |
|---|---|---|---|
| Create or update patients and appointments | Supported, with Open Dental's validation | Not safe: bypasses business rules | API |
| Show today's schedule in your app | Appointments and Operatories resources | Possible, but duplicates API work | API |
| Treatment plan estimates and reminders | ProcedureLogs and InsPlans | Possible for batch reports | API, database for history |
| Practice production and collections reporting | Partial, many calls per report | Documented tables, one query | Read replica |
| Multi-location DSO analytics | Per-practice keys and rate limits | Replica per database, central warehouse | Read replica |
| Claim status and ERA reconciliation | Claims resource plus your clearinghouse 835 | Claim tables for history | API plus X12 835 |
Practices hosted on Open Dental Cloud may not be able to give you database access, so cloud practices usually run API only. We confirm hosting per practice before scoping.
Each module is scoped on its own, so a first release can be one of them and still be useful to the practice.
Two-way sync of demographics, appointments and confirmations, with matching rules so a patient edited in Open Dental is the same patient in your product.
Planned and completed procedures by CDT code, fee schedule and insurance estimate, for case acceptance tools, patient financing and recall logic.
Claim creation and status from Open Dental, submission through your clearinghouse as an 837D, and 835 remittance posted back against the claim.
Online scheduling built on provider and operatory availability, recall outreach from Open Dental's recall rules, and reminder outcomes written back.
Radiographs, intraoral photos and signed forms attached to the right patient and visit through the Documents resource, with DICOM where your imaging source supports it.
Read-only extracts from a database replica into your warehouse for production, collections and hygiene reporting across one practice or a DSO.
Failure points
These are the points we design for, because they fail quietly and show up as wrong data at the front desk.
Challenge
Duplicate patients after a two-way sync
Agnotic approach
Deterministic matching on Open Dental's patient number first, then a review queue for near matches instead of silent merges.
Challenge
Writing to the database directly and breaking Open Dental's rules
Agnotic approach
All writes go through the API so Open Dental validates them. Database access is read only, on a replica.
Challenge
Appointment status drift between systems
Agnotic approach
One system owns each status, status changes are events with timestamps, and a nightly reconciliation report lists mismatches.
Challenge
CDT and fee schedule changes each year
Agnotic approach
Procedure codes are versioned in the mapping layer and fee schedules are read from Open Dental, never copied into your product.
Challenge
API keys shared across practices in a DSO
Agnotic approach
One customer key per practice, least-privilege permissions per key, and rotation handled in a secrets manager.
Challenge
Claims rejected at the clearinghouse
Agnotic approach
837D validation before submission, payer-specific edits kept in configuration, and rejection reasons written back to the claim for staff.
HIPAA applies to the practice, to Open Dental and to your product. We make the safeguards concrete decisions rather than a policy document.
Agnotic signs a BAA with you before any PHI is shared, and Open Dental expects API developers to hold a BAA with each practice they serve.
API permissions are scoped to the resources each module uses, database access is read only, and every practice has its own credentials.
TLS for every API call, encryption at rest for synced data, and keys kept in a secrets manager with rotation, never in configuration files.
Every read and write records who, which patient, when and why, so the practice can answer an access request or investigate an incident.
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Scope drivers
There is no fixed price for an integration. These are the factors that move the effort, and we size each one on the scoping call.
Reading the schedule is a small scope. Writing appointments, patients and claim updates adds matching rules, conflict handling and testing against a practice.
One practice with a local server differs from a DSO with dozens of databases or Open Dental Cloud. Each adds credentials, replicas and rollout steps.
837D submission, payer edits and 835 posting bring a clearinghouse into scope and need end-to-end testing with real payers.
Linking radiographs and forms means handling large files, retention rules and sometimes DICOM, which is its own workstream.
A handful of production metrics is quick. A full warehouse model of procedures, fees, adjustments and payments is a data project.
Startups integrating a first product need the data model designed alongside the integration. Established products mostly need mapping.
Who builds on Open Dental
The same integration surface, used by very different products.
Patient engagement, financing and case-acceptance products that need live schedule and treatment plan data from day one.
Central reporting and patient communication across many Open Dental databases.
Radiograph analysis and charting tools that need the procedure and imaging context from the practice record.
Claim status, 837D submission and remittance posting across client practices.
Availability by provider and operatory, confirmations and recalls written back to the chart.
Production, collections and hygiene metrics from a read-only replica into a warehouse.
Four steps, with a fixed first release agreed before any code is written.
We list the data you need, which direction it moves, how your practices host Open Dental and which modules make a useful first release.
We complete Open Dental's API developer setup, request permissions, and build against a test database with synthetic patients, never live PHI.
Mapping, sync jobs, audit logging and reconciliation reports for the agreed modules, tested with a pilot practice before wider rollout.
Per-practice onboarding, monitoring of failed syncs and claim rejections, and a plan for Open Dental version and CDT updates.
Standards in scope
Short facts we design around, each linked to its primary source.
The Open Dental API is a RESTful service for reading and writing an Open Dental database, and Open Dental states that API developers should have a Business Associate Agreement in place with their clients.
Source: Open Dental, API SpecificationOpen Dental stores its data in a MySQL or MariaDB database; the Open Dental installer supports MySQL 5.5 or MariaDB, and other versions are not supported.
Source: Open Dental manual, MySQLIn version 24.4 the Open Dental licence changed from open source GPL to proprietary; Open Dental says the change did not affect customers' database access or how the software is used.
Source: Open Dental manual, LicenseHIPAA adopts the ASC X12N 837 Health Care Claim: Dental (version 005010X224) as the standard transaction for dental health care claims.
Source: 45 CFR 162.1102 (eCFR)HIPAA adopts the Code on Dental Procedures and Nomenclature (CDT), maintained and distributed by the American Dental Association, as the standard code set for dental services.
Source: 45 CFR 162.1002 (eCFR)
