Open Dental API Guide: What You Can Build and How to Start

Dental practices use software to manage appointments, patient records, treatment plans, and payments. But what happens when a practice wants to connect this software to a website, patient portal, or reminder tool?

This is where the Open Dental API can help.

The Open Dental API allows approved applications to exchange information with Open Dental, a dental practice management system. Developers can use it to connect different tools and reduce manual work.

For example, a dental practice may want to show appointment details on its website or send automatic reminders to patients. An API integration can help make these tasks easier.

However, every integration has its own requirements. Developers must understand which information they can access, which records they can change, and what permissions they need.

This guide explains how the open dental api works, what you can build with it, and how to get started. It also covers HIPAA requirements and the differences between Open Dental and Dentrix integrations.

What Is the Open Dental API?

The Open Dental API is a way for other software applications to communicate with Open Dental.

API stands for Application Programming Interface. It allows two applications to exchange information without requiring users to enter the same details in both systems.

For example, a patient portal can retrieve approved appointment information from Open Dental. A separate application may also create or update supported records.

The Open Dental API uses REST, a common way for applications to communicate over the internet. It sends requests and returns information, usually in JSON format.

The API supports four main request types:

• GET: Retrieves existing information.
• POST: Creates a new record when supported.
• PUT: Updates an existing record when supported.
• DELETE: Removes a record when supported.

These actions depend on the resource and the permissions granted to the application.

Open Dental also provides a separate FHIR API. FHIR is a standard for exchanging healthcare information between different systems. The standard Open Dental API is generally recommended for most Open Dental integrations.

Developers can review the official Open Dental API documentation to understand the available resources and operations.

What Data Can You Access Through the Open Dental API?

The Open Dental API provides access to different types of dental practice information.

The exact data and actions depend on the API resource, permissions, and software version.

Here are some common examples.

Patient information

Applications can retrieve supported patient details, such as names and contact information. This can help connect patient records with approved external applications.

Appointments

Developers can retrieve appointment details, check available appointment slots, and create or update appointments through supported operations.

Treatment and procedure records

Supported resources allow applications to work with procedure information and related records.

Payments and billing

Applications can access supported payment and billing information. The available operations depend on the resource and assigned permissions.

Providers and clinics

An integration may retrieve provider and clinic information to support appointment scheduling and practice management tools.

Reading and updating information

There is an important difference between reading information and changing it.

Read access allows an application to retrieve information without changing the original record. For example, a reporting dashboard can display appointment information.

Write access allows an application to create or update supported records. For example, an online booking tool may create an appointment in Open Dental.

Before enabling write access, developers should decide which application can make changes. They should also plan how to handle duplicate records, failed requests, and conflicting updates.

This helps keep information accurate across connected systems.

How to Get Started With Open Dental API Integration

Before starting an Open Dental API integration, developers should understand the practice's requirements and complete the required setup.

Step 1: Define the integration requirements

Start by deciding what the application needs to do.

For example, an appointment reminder tool may need access to appointment dates and patient contact details. It may not need treatment records or payment information.

Make a list of the required data and actions before requesting API access.

Step 2: Request developer access

Open Dental requires developers to obtain a developer API key.

Start by reviewing the Open Dental API setup guide.

Developers must provide information about their application and the API resources they need. They must also identify whether they need permission to read, create, or update information.

Step 3: Get the customer API key

Remote API access requires two keys:

• A developer API key.
• A customer API key.

The customer key connects the integration to the relevant dental practice.

The practice must enable the API and approve the required customer key. The practice can also disable a key when access is no longer needed.

Step 4: Configure the eConnector

For remote API access, the practice must have a working eConnector.

The eConnector is a service that helps connect the practice's Open Dental database to the remote API service.

If this service stops working, remote requests may fail. Developers should include connection checks in their testing process.

Step 5: Test the API connection

Test the integration before using it in a live environment.

A tool such as Postman can help developers send API requests and review the responses.

Check that:

• Authentication works correctly.
• The application can access the required records.
• Users cannot access information without permission.
• Failed requests return useful error messages.
• Repeated requests do not create duplicate records.

Testing these situations can help prevent problems after launch.

Three Things You Can Build With the Open Dental API

The Open Dental API can support different types of dental applications. The exact features depend on the available resources and the practice's setup.

1. Online appointment booking

A dental practice may want patients to request appointments through its website.

An integration can connect the website with Open Dental's appointment resources.

For example, the application can retrieve available appointment slots and display suitable options to patients. The API also supports creating appointments through its POST operation.

However, showing available slots and confirming an appointment are two different steps.

The application must consider provider schedules, appointment types, existing bookings, and the practice's rules. It should also prevent two patients from booking the same time.

If staff approval is required, the website should clearly show that the appointment is waiting for confirmation.

2. Automated appointment reminders

Dental practices can connect Open Dental with an email or text message service.

For example, an application can retrieve upcoming appointments and send reminders to eligible patients.

A reminder system should:

• Send messages at the correct time.
• Avoid sending the same reminder twice.
• Account for canceled or changed appointments.
• Follow patient communication preferences.
• Record message delivery status.
• Avoid including unnecessary private health information.

The application should also handle failed messages. A request accepted by a messaging service does not always mean the patient received it.

3. Patient portals and reporting tools

A patient portal gives people another way to view approved information about their appointments and dental care.

Depending on the available API resources, the portal may retrieve selected patient and appointment information from Open Dental.

Reporting tools can also use supported data to show appointment activity and other practice information.

Both applications need clear access rules.

Patients should only see their own information. Staff should only access the records needed for their work.

Developers should also consider how often information is updated. A record stored in another application may become outdated when someone changes it in Open Dental.

For more information about planning these connections, read EHR Integration Patterns for Healthcare SaaS.

Open Dental API Modes: Local, Service, and Remote

Open Dental offers three API modes. Each has a different setup.

The right choice depends on where the application runs and how it needs to connect to the dental practice.

Local mode

The application communicates with Open Dental on a local workstation. This can work for tools used inside a dental practice.

Service mode

The API runs as a service on a computer connected to the practice database. This can support applications that need access through the practice's local network.

Remote mode

The application sends requests through Open Dental's hosted API service. This can support applications that need to connect from outside the practice.

Remote access requires the correct API keys, an enabled API, and a working eConnector.

Before choosing a mode, developers should review the Open Dental API modes documentation.

They should consider the application's location, network setup, security needs, and maintenance requirements.

HIPAA Requirements for Dental API Integrations

Dental records can contain protected health information, also called PHI. This includes patient details, contact information, and information about dental treatment.

If an application handles PHI, the organizations involved must understand their HIPAA responsibilities.

Using the Open Dental API does not automatically make an application HIPAA compliant. Compliance depends on how information is accessed, stored, shared, and protected.

Here are some important areas to consider.

Use the right agreements

Open Dental states that API developers should have a Business Associate Agreement, or BAA, with their clients.

A BAA explains the responsibilities of organizations that handle protected health information under a business associate relationship.

Other service providers that handle PHI may also need appropriate agreements.

Limit access to necessary information

Give each application only the permissions it needs.

For example, an appointment reminder tool may need appointment dates and patient contact details. It may not need access to treatment notes or payment records.

Keep API keys private and store them securely. Remove access when an application no longer needs it.

Protect stored and shared information

Use secure connections when sending information between applications.

Protect stored patient records, backups, and logs from unauthorized access.

Do not place API keys in public code or include sensitive patient details in error messages.

Keep useful audit logs

Audit logs help teams understand what happened in an application.

They should record:

• Who or what accessed the information.
• Which action was attempted.
• When the action happened.
• Whether the action was allowed or denied.

Protect these logs from unauthorized changes. Avoid recording full patient details when they are not needed.

Test access controls

Check that patients cannot view another patient's records.

Also test what happens when an API key is disabled or the connection becomes unavailable.

Developers should check how the application handles failed updates and repeated requests.

For a broader checklist, read HIPAA Compliance for SaaS.

Dentrix API Integration: What You Need to Know

Open Dental is not the only dental practice management system developers may need to connect with.

Dentrix and Dentrix Ascend have separate integration requirements. Developers should confirm which product the dental practice uses before planning the work.

Dentrix API integration

Dentrix desktop software has its own developer program.

Henry Schein One manages this program and provides approved developers with API documentation, credentials, and development resources.

The program includes different API options for reading information, writing information, and managing appointments.

Developers must apply and receive approval before using the program.

Visit the Dentrix Developer Program to review the requirements.

Dentrix Ascend API integration

Dentrix Ascend is a cloud-based dental practice management system.

Its integrations are managed through the Henry Schein One API Exchange program.

For a Dentrix Ascend API integration, developers should review the Henry Schein One API Exchange.

The team should confirm the application requirements, approval process, supported data, and access permissions before starting development.

Access to general program information does not mean that every API feature is available to every application.

Which API should you use?

The right choice depends on the software already used by the dental practice.

If the practice uses Open Dental, start with its API documentation and setup requirements.

If it uses Dentrix or Dentrix Ascend, review the correct developer program and available integration options.

Each platform has its own requirements. Developers should not assume that an integration built for one system will work with another.

For more background on healthcare data connections, read Integrating EHR Systems with FHIR and EHR vs. EMR.

Common Challenges in Dental API Integration

Even when API documentation is available, developers may face some practical challenges.

Different data formats

Two applications may store the same information in different ways. Developers need clear rules for matching fields and keeping records accurate.

Duplicate records

A repeated request may create a duplicate appointment or record if the application does not check whether the action has already happened.

Access restrictions

Some API operations require specific permissions. Others may depend on the practice's software version.

Changes in practice workflows

A dental practice may change its appointment process or communication rules. The integration should support these changes without creating errors.

Ongoing maintenance

Network problems, disabled API keys, and failed requests can interrupt an integration.

Regular monitoring helps teams find problems and fix them before they affect daily work.

Planning for these situations early can make an integration easier to manage.

Frequently Asked Questions

Planning Your Dental API Integration

A dental API integration starts with a clear plan. The team needs to understand the practice's workflow, the available API operations, and the information the application needs.

It is also important to plan for access permissions, failed requests, accurate records, and patient privacy.