Integrations

Open Dental Integration

Open Dental is Clincy's first integration, and it is first for a specific reason: it ships a documented API that lets an external tool both read the schedule and write structured data back onto the patient record. That second half is the part most dental tooling skips. Collecting intake information is straightforward; getting it into the chart as fields the practice can actually bill and treat from is where integrations either work or quietly become a copy-paste job for the front desk.

What the integration reads and writes

The integration is deliberately narrow. It watches for new patients appearing on the schedule and it writes back the fields intake collects. It does not touch clinical notes, the ledger, or claims.

Direction	Data	Purpose
Read	New appointments and their patient records	Detect who needs intake and when their visit is
Read	Existing patient fields	Avoid re-asking for information already on file
Write	Demographics: address, mobile, email, preferred contact and language	Complete the patient record and fix recall data at source
Write	Insurance: carrier, member ID, group number, subscriber and relationship	Give verification complete inputs before the visit
Write	Medical history: conditions, medications, allergies	Surface clinical flags before the patient is in the chair
Write	Intake summary note	Give the clinical team a readable pre-visit picture

Setup steps

Setup is an Open Dental configuration task plus a mapping review. It does not require a database migration or downtime, and it is reversible, revoking the API key stops all access immediately.

Confirm your Open Dental version supports the API and that the API service is enabled. Open Dental's developer documentation is the authority here; your Open Dental support contact can confirm your build.
Generate a customer API key from within Open Dental and scope it to the minimum set of permissions the integration needs. Do not reuse a key issued for another vendor.
Provide the key to Clincy through the secure onboarding step rather than by email.
Review field mapping. Practices customise Open Dental more than they remember, a clinic that uses a custom field for preferred language needs that mapped explicitly or the value lands nowhere.
Choose the trigger. The default is 'new patient appointment created', but practices with a long booking-to-visit window sometimes prefer a delay so outreach lands closer to the visit.
Run a supervised pilot on a handful of appointments and verify each field landed on the patient record where the coordinator expects to see it.
Define the exception path, who works the list of patients the automated flow could not complete.

A typical workflow, end to end

The sequence below is what a single new patient looks like from booking to arrival. The point of writing it out is that most of it happens with no front-office involvement at all, and the one step that does need a person is bounded and visible.

A patient books online or the coordinator adds them to the schedule, which creates the appointment in Open Dental. Clincy detects the new appointment and starts outreach in the patient's stated channel, or by SMS if no preference is recorded. The patient answers demographic and insurance questions, photographs or reads their card details, and works through the health history questions. Anything they skip is followed up once, later, rather than abandoned. As answers come in, fields are written back to the Open Dental patient record. Two days before the visit the coordinator sees which records are complete and works a short list of the ones that are not. At check-in the patient confirms rather than fills in.

Use cases beyond first-visit intake

The same read-write loop supports adjacent workflows once it is in place, though intake is the one worth proving first:

Annual health history re-confirmation for recall patients, which practices rarely do rigorously because it is manual.
Correcting stale contact data, capturing a mobile number for a patient whose record only has a landline.
Insurance re-capture in January, when plans change and the practice is holding last year's group numbers.
Pre-visit collection for patients whose treatment plan requires a medication or condition check before an invasive procedure.

Practical constraints worth knowing before you plan

Open Dental deployments vary more than the product name suggests. Practices self-host on a local server, run it through a hosting provider, or sit on a version several releases behind current. Network access, API availability, and which fields exist all follow from that.

The two questions that determine whether setup is a half-day or a multi-week project: is the API reachable from outside the practice network, and how heavily has the practice customised its fields and definitions. Neither is a blocker, but discovering them after a rollout date has been announced is a bad experience for everyone.

Frequently asked questions

Does this require changing how Open Dental is configured?

It requires enabling API access and issuing a scoped key. It does not require changing your field structure, your appointment types, or your existing workflows, the mapping step adapts to how your practice already uses the system.

What happens to data the patient provides that has no matching field?

It goes into the intake summary note rather than being discarded, so the clinical team can still see it. During the mapping review it is worth flagging anything you would rather have as a structured field.

Can access be revoked?

Yes. The integration authenticates with a key issued from inside Open Dental, and revoking that key stops all reads and writes immediately without involving anyone outside the practice.

Is Dentrix, Eaglesoft, Curve Dental, Denticon, or CareStack supported?

Not yet. Open Dental is the MVP integration and the others are planned. If you are on one of those systems, treat the integration as roadmap when you evaluate, worth a direct conversation about timing rather than a rollout plan built on it.

Running Open Dental? Book a call and we will walk through the field mapping for your specific configuration before anything is connected.

Book Call