
Appointment & Scheduling Access
Read appointment slots, book new appointments, update appointment status. Core for AI receptionist and scheduling automation products.
Open Dental integration is how a dental or hybrid healthcare product reads and writes data from a practice running Open Dental pulling appointment schedules, patient records, and clinical notes through the Open Dental REST API. Done from scratch it requires navigating a custom authorization model, a polling architecture, and a practice-side vendor approval process that most teams hit cold. Done with Mindbowser, it is a known path we have run in production.
Open Dental integration projects stall in a predictable place: the REST API is proprietary, there is no OAuth and no webhook support, and its FHIR API is a separate surface aimed at medical-system interfacing. Patient and appointment data access is not yet available through the ConnectHealth connector. Mindbowser builds the data layer directly against the Open Dental REST API — production integrations completed, with ongoing engagements across dental and dental AI accounts. Open Dental is one of Mindbowser’s verified integrations.
ConnectHealth and Open Dental today: The ConnectHealth platform includes an Open Dental connection that handles API authentication confirming the key pair authenticates against a non-PHI endpoint. Open Dental has not yet exposed patient and appointment endpoints through that path. In the meantime Mindbowser builds the full integration layer directly against the API. When Open Dental expands its endpoint surface, ConnectHealth will absorb that work automatically.
What that means in practice: your product gets the integration now, not when the platform catches up. Teams integrating both systems can see our approach on the Epic integration page.
The practice emails vendor.relations@opendental.com requesting API access as their own API vendor.
Open Dental reviews the request and approves the practice. Approval is not instant.
The practice generates a Customer Key from inside Open Dental.
Paste the key into:
The practice keeps the eConnector service running. API calls fail if eConnector is stopped.
Mindbowser has been through this process. We know where it stalls, what the approval timing looks like, and how to support practices through it. We document this for every engagement.
All features operate through the Open Dental Remote API (`api.opendental.com/api/v1`). Local and Service port modes (`:30222`, `:30223`) are not reachable externally. Authorization uses dual static keys a Developer Key (your application) and a Customer Key (the practice) passed in a custom `Authorization` header. Keys are practice-specific (BYOK).

Read appointment slots, book new appointments, update appointment status. Core for AI receptionist and scheduling automation products.

Pull patient demographics and contact data. Note: CDT procedure codes are the dental billing standard not ICD-10 and must be mapped correctly for any claims or analytics workflow.
Read clinical notes and chart entries for analytics, AI summarization, or cross-platform display.
Open Dental does not run real-time electronic eligibility against payers, it tracks verification status. Mindbowser builds the bridge: pull patient data from Open Dental, pass to Stedi, Availity, or another clearinghouse, write results back. This is a pattern dental practices and DSOs are actively requesting.

Pull production data for reporting dashboards, DSO-level analytics, or AI-driven insights. This is the core use case for dental AI platforms that aggregate across practice locations.
For networks running multiple PMS systems, Mindbowser normalizes data out of Open Dental into a shared model that other practice management systems can read from.
These constraints are Open Dental's — stating them plainly is what serious integration partners do.
Open Dental uses dual static keys in a custom Authorization header. There is no OAuth 2.0 flow, no token refresh, and no FHIR resource mapping on this API. Open Dental does publish a separate FHIR API, but it targets medical-system interfacing rather than dental practice workflows — most dental product integrations run on the REST API.
Any data access requires polling the API on a schedule. There are no push events. For real-time use cases such as AI receptionist call flows and live scheduling, the polling interval and retry logic have to be engineered deliberately.
Any sync job that ignores this will hit 429s and stall silently. Auto-retry with exponential backoff is required, not optional.
The practice owns the API key, not the vendor. If the eConnector service is stopped on the practice's server, all API calls fail. Integration reliability depends on practice-side infrastructure you do not control.
Dental billing uses CDT procedure codes. Any eligibility, claims, or analytics workflow that assumes ICD-10 will produce incorrect data. Write-back integration in particular is technically complex: dental PMS has a limited API surface, and CDT codes don't map cleanly onto standard ICD-10 medical billing logic.

Open Dental is open-source and widely adopted by independent practices and smaller DSOs. Integration unlocks a segment that enterprise EHR integrations do not reach.

Mindbowser has run production Open Dental integrations. Known path, documented gotchas, no discovery phase for the API model.

A dental AI product or analytics platform that tells practices exactly what the integration can and cannot do wins trust faster than one that oversells. We build pages and products the same way.

The Stedi eligibility and write-back pattern is built, and it's in active scoping with multiple dental accounts. Prior authorization is a custom build on top — it isn't a standard clearinghouse transaction on the dental side. See the eligibility verification calculator for a closer look.
Patient, scheduling, billing, and practice data
Read appointment slots and patient contact data to power AI call bots and scheduling agents. Open Dental polling + queue management + outbound SMS/voice.
Mindbowser builds the eligibility layer: pull patient plan data from Open Dental, pass to Stedi or Availity, write verified eligibility result back. CDT-aware mapping required. Active requests across multiple dental practice and DSO accounts.
Aggregate production data across practice locations for dashboards, KPI tracking, and AI-driven insights.
For networks running Open Dental alongside other practice management systems, Mindbowser normalizes the data layer for referral exchange and patient record handoffs.
If your product needs to read or write Open Dental records to serve dental practices, Mindbowser builds the integration layer — handling the auth model, polling architecture, CDT mapping, and practice-side vendor application support.
Deep healthcare knowledge ensures the integration aligns with real dental workflows, not just API documentation.
Pre-built components and a documented Open Dental integration path reduce engineering time. ConnectHealth handles authentication today and absorbs expanded endpoint coverage as Open Dental ships it.
Hands-on experience with dental clearinghouses (Stedi, Availity) and the Open Dental vendor program process.
100% ownership with a perpetual license for IP and code. The integration layer you build with Mindbowser is yours.
Built to scale across single practices, multi-location groups, and DSOs.
We tell you what the integration can do today and what requires a roadmap. No overselling the API surface.
ConnectHealth is Mindbowser’s AI-first healthcare integration engine. Connect to Epic, Cerner, Athena, and 20+ EHRs, deployed inside your own AWS VPC so PHI never leaves your environment. Helix AI generates production-ready FHIR and HL7 workflows from plain English. No custom code. Predictable pricing. Sandbox in minutes.

Partner with us to design, build, and scale digital solutions that drive better outcomes.
Global Tech Teams LLC, 525 Washington Blvd, Industrious at Newport Tower, Jersey City, NJ 07310, United States.
Let’s discuss your goals, workflows, and next steps in a focused consultation call.