HubSpot + Open Dental integration

Dentistry has an inventory problem that has nothing to do with teeth. Chairs are the inventory, and an empty chair on Tuesday afternoon cannot be sold on Wednesday. Open Dental knows every gap in the book, every overdue hygiene recall and every patient who cancelled and never rebooked. None of that reaches the people running campaigns, because the practice system sits on a server in the office and marketing sits in a browser tab.

Multi-location groups feel it hardest. A practice manager can work a recall list by hand for one office. A group with six offices cannot, so it either buys a point solution per practice or sends the same generic message to everybody on file. Neither approach knows which patient is genuinely due, or whether they have already booked.

Moving the scheduling layer into HubSpot turns those lists into workflows. A recall due date becomes an enrolment trigger. An appointment that moves to broken pulls the patient back into a rebooking sequence. New patient enquiries from a web form stop dying in an inbox, because the form can create the patient and the appointment request in the practice system directly. One constraint shapes everything else, which is that the chart stays in Open Dental.

Five record types leave the practice and one category never does. Patients become contacts, carrying contact details and the practice record number. Appointments become a custom object associated to the patient, holding the date, the office, the provider and the status. Recalls become their own custom object, because a due date is the trigger a campaign actually needs. Appointment types and providers come across as small reference objects so a workflow can route by chair and by office without guessing.

Procedures, treatment plans, charting, imaging and claims stay in Open Dental. They are all reachable through the same API, which is exactly why the field list has to be written down rather than assumed. A practice that wants any of it in HubSpot needs the sensitive data settings turned on and an agreement that says so.

Everything keys on the Open Dental record number, written to a unique HubSpot property. Households share email addresses constantly in dentistry: parents book for children and spouses share an inbox. Email as a match key merges a family into one contact almost immediately.

Open Dental offers something most practice systems do not: a subscription that pushes. An API subscription names a table to watch, a polling interval for the practice side to check it against, and an endpoint of your choice to call when something changes. Events arrive at a small receiver we host, land on a queue, and a worker performs the HubSpot write. The queue earns its place because the practice’s own software is what polls its database, so a burst of edits arrives together.

Writes are idempotent batch upserts keyed on the source record number, followed by a separate associations pass linking appointments and recalls back to the patient. HubSpot API paths are pinned to the 2026-03 version, so a platform change never arrives unannounced.

The queue also absorbs the API’s pacing. Requests for one customer key are processed in order, and a key holding read-only permission is throttled harder than one with write access. The worker drains at a rate the practice tolerates rather than as fast as the queue fills.

What decides here is whether you need the events. A healthcare automation platform can read patients and appointments on a schedule, and two of them connect Open Dental today from outside the HubSpot App Marketplace. If the practice wants a nightly list of who is due, that is a sensible answer, it arrives quickly, and there is nothing to maintain.

It stops being enough when timing matters. A broken appointment that should trigger a rebooking sequence within the hour, a web form that should create the patient before the caller hangs up, or a group routing by office and provider: each needs the subscription events and somewhere to put the logic. Control is the other deciding factor. A practice under a business associate agreement has to state what left the building, and a service with a signed field list answers that on one page.

Access, the practice’s connector service, the per-key throttle and duplicate families are what go wrong, and access costs a project time before it starts.

1. Scope. We submit the developer key request and its permission list first, because it is the long pole, and we write the field list with the practice while it is being processed.
2. Architect. The object model, the identifier property per object, the recall and appointment status maps, and which subscriptions the practice will run.
3. Build. The event receiver, the queue and the worker, plus a paced backfill that runs on a separate budget from live traffic.
4. Validate. A sandbox portal first, behind a fail-closed portal allowlist so a misconfigured key cannot write into the wrong portal. Production cutover is a key swap.
5. Operate. Heartbeat monitoring on the subscription, a replay endpoint that re-runs from a chosen point, and a reconciliation count of patients and appointments on both sides.