September 10, 2026 Open API vs Partner-Gated: Which Dental AI Vendors You Can Actually Integrate With
A dental AI model can be brilliant and still be unreachable. The detection accuracy, the FDA clearances, the polished chairside demo – none of it matters to your practice until an image can physically travel from where it is captured to the engine that reads it, and the finding can travel back. That path is governed not by how clever the AI is, but by how the vendor chose to open its door. Some publish a documented interface and accept images in standard formats from anyone willing to build to the specification. Others keep the door shut and open it only for companies they have formally partnered with. If you think of your imaging software as the gallery where every radiograph and photograph is held, the practical question is unromantic and decisive: which of these AI engines can the gallery actually hand a picture to? This is the companion to our broader look at how dental AI connects to imaging software – where that piece maps the four plumbing methods, this one reads the vendors through a single question: open or gated.
Two doors: the open API and the partner gate
Strip the category down and there are two kinds of access. An open API is a documented, published interface – usually a REST endpoint, sometimes a FHIR one – that any approved developer can build against after signing the appropriate agreements. The specification is public, the behaviour is predictable across versions, and you are not waiting on anyone’s business-development calendar to make a connection work. A partner gate is the opposite posture: the integration exists, and it may be excellent, but it is only available where the AI vendor has struck a formal deal with your imaging or practice-management software. You cannot wire the two systems together yourself, however capable your IT is, because the connecting code lives behind a partnership you are not party to. Most of the dental AI market sits on the gated side of that line, and understanding why tells you a great deal about which tools you can realistically reach.
The genuinely open end: documented REST and FHIR
The clearest example of an open surface in dentistry is not an AI company at all – it is Open Dental, whose practice-management platform exposes a openly documented public REST API (and a parallel FHIR interface) at a published base endpoint. Approved third-party developers can read and write patient data, appointments, procedures, claims and more, provided they hold a Business Associate Agreement with the practice. That openness matters for AI because the practice-management system is where findings ultimately need to land next to the chart; a PMS with a real API is one you can integrate against on your own terms rather than waiting to become an approved partner. Open Dental is the standards-friendly pole of the market, and it is worth naming precisely because so little else is built this way.
The lesson generalises. When a vendor – of any kind – says it has an API, the questions that separate a genuine open surface from marketing language are: is the specification documented and public, can a new developer be approved without a bespoke commercial negotiation, and is the interface versioned so an integration does not silently break on the next release. Open Dental answers all three. Few dental AI vendors do.
DICOM and the cloud API: the image-transport middle ground
For imaging specifically, the most honest open channel is not a proprietary API at all – it is DICOM, the interoperability standard that every serious scanner, archive and CBCT unit already speaks. A tool that accepts DICOM can ingest a volume or a set of radiographs regardless of which vendor captured them, because they all share the same container and the same store-and-query network operations. DICOM support is the single strongest signal that an AI tool is built to accept images from outside its own walls.
Diagnocat sits furthest toward the open end of the imaging AI pack. It is cloud-native, it segments and accepts DICOM directly, and its enterprise tier explicitly includes API integration and customised connection work – meaning an imaging platform can, in principle, hand it a study programmatically and receive structured findings back. We traced that route in detail in Diagnocat on CBCT volumes and the API path. The caveat to keep honest: “API integration” on an enterprise plan is still a commercial arrangement, and “supports DICOM” is a spectrum – a vendor may accept a DICOM export yet not answer a live query. The word alone never tells you how automated the flow will be; the specification does.
The partner gate: Overjet, Pearl, and the OEM embed
The two highest-profile names in dental AI both sit, for the most part, behind partner gates – and have built formidable businesses there. Overjet delivers its AI as OEM and partner integrations embedded into imaging systems and practice-management software – Open Dental, Dentrix, Eaglesoft, Oryx, CareStack and others – through connector software and DICOM image routing. There is no open, self-serve public endpoint a third party can simply call; the reach comes from Overjet being an approved partner inside each of those products. Pearl follows the same playbook at scale, advertising native Second Opinion integration inside the imaging software a practice already uses, with more than forty integrations and operations across 120-plus countries. Where Pearl does expose an API, it tends to surface through a partner’s developer program – as with its API-based integration distributed through ClearDent’s Developer Program in Canada – rather than as an open door to the public. VideaHealth, which we examined in how TWAIN feeds the AI, reaches the image at the acquisition layer through TWAIN-capable imaging software, which is its own form of gating: you integrate where the imaging software already cooperates.
None of this is a criticism of the tools. Partner-gating buys quality control, a supported integration surface, and a defensible business. But it changes what you can do: your ability to connect is contingent on a partnership you do not control, and the same product can install effortlessly in one practice and be simply unavailable in another. We walked through what a mature gated bridge looks like from the clinical side in how the image reaches Pearl by DICOM.
So which can you actually integrate with?
Read the market through the single question of reachability and a rough ranking emerges. At the open end sit the standards and the documented interfaces: DICOM as a universal image-transport rail, Open Dental’s public REST and FHIR APIs on the practice-management side, and Diagnocat’s DICOM-plus-enterprise-API model as the most directly addressable imaging AI. In the middle sit the partner-gated platforms – Overjet and Pearl – which are entirely integrable, but only through an approved partnership and connector software, not a port you open yourself; and VideaHealth, reachable at the TWAIN acquisition layer where the imaging software plays along. At the far end sit closed ecosystems built on proprietary hardware and a sealed app, with no third-party surface at all – genuinely excellent within their lane, and effectively a dead end for anyone wanting to route images in or out. The practical rule for a buyer or a builder is unchanged: favour the standards-based paths – DICOM and documented APIs – because they are the ones that keep the choice, and the image, yours.
What this means for the gallery
There is a deeper reason to care about this map than vendor selection. If the imaging software is where radiographs and photographs are acquired and held, then it is the natural place from which to send an image out to whichever AI engine suits the case – a caries detector here, a CBCT segmenter there, a reporting engine for the referral – and to receive the findings back into the record. That vision only works to the degree the destination engines expose a reachable door. The open-and-DICOM-friendly vendors can be wired in directly; the partner-gated ones require the imaging platform itself to become an approved integration partner; and the closed ecosystems cannot be reached at all. The shape of this market, in other words, is the shape of what an imaging hub could ever offer – which is precisely why the open-versus-gated line is worth watching rather than taking on faith from a demo.
Future Developments
The honest trajectory is toward more open doors, slowly and unevenly. DICOM and documented REST or FHIR interfaces are becoming table stakes for serious tools, and the vendors that publish real specifications rather than partnership forms will be the ones an imaging platform can compose into a genuine send-out-and-return workflow. The craft to watch for is not the AI’s detection score but its interoperability posture: a standards-based, well-documented, versioned door is the quiet feature that determines whether a radiograph can be sent to the best engine for the case and returned, annotated, to the gallery where it belongs. As that discipline spreads, the distance between capturing a beautiful radiograph and getting a second set of eyes on it – any set of eyes you choose – should narrow to something close to a single click. The tools that make that possible will be the ones that treated the open door as part of the craft, not an afterthought.
Sources & further reading:
- Open Dental Software – API Developer Setup & Specification
- ClearDent Integrates Pearl Dental AI Platform (Dentistry Today)
- Complete Guide to AI-Powered Dental Software Integrations (Overjet)
No Comments