See API Specification

The API web service is hosted at Open Dental headquarters. All requests are routed through this address to the appropriate office. The API Key specified in the Authorization header is linked to a specific office.

For additional information on integration types, see: Open Dental Integration Types.

Steps to Enable the API

See API Guide - Getting Started.

In order to use the Remote API, the office must have an eConnector running. See eConnector for installation instructions.

Then, the developer will work with the customer to enable the API within Open Dental. Have the customer go to API Setup and check the Enabled checkbox. This is also where additional customer keys can be created and disabled.

For setup information for other API modes, see API Modes - Local, Service, and Cloud.

API Keys

When requesting data from the API server, two API keys must be present in the request header: a Developer API Key and a Customer API Key. The Developer API key is unique to each developer and is obtained by logging into the Developer Portal. Customer API Keys are unique to each customer/developer pair and generated by the developer within the portal.

To obtain Developer Portal access contact vendor.relations@opendental.com. Please include the details below.

Product/Integration Owner (Company Name):
Contact Phone Number:
Email address for long-term billing:
Mailing address for long-term billing:
3rd Party Developer Name (if any):
3rd Party Developer Email Address:
A list of the API resources you need access to and for each permission, whether you need read, create, or update for that permission:
A description of the application you are intending to build (type and purpose):

To assign a Customer API key to an Open Dental customer, they will go to Setup > Advanced Setup > API. Click the Add Key in the lower left. Here is where you paste a key generated from the developer portal. The customer has the ability to enable or disable a key. The customer can view permissions granted to that key, but they cannot change those permissions. The interface in this window displays information from our HQ server, not the customer database.

When using the window described above, a copy of the keys are placed in a table in the customer's local database called "apikey". This table will then contain the customer's apikeys and each corresponding developer name exactly as entered in the developer portal. Occasionally, you may want to retrieve this information via a query. This will be rare, but can be accomplished with the following example:

SELECT CustApiKey FROM apikey WHERE DevName='YourName';

Developer Portal

The Developer Portal is where third-party developers can add or move keys, see key permissions, or edit account details. The process of moving a key may take up to 15 minutes to take effect.

Authorization

Each API request must include an Authorization header in this format:

Authorization: ODFHIR {DeveloperKey}/{CustomerKey}

For testing, the following credentials can be used:
Authorization: ODFHIR NFF6i0KrXrxDkZHt/VzkmZEaUWOjnQX2z

Testing

We use Postman for testing API requests and Webhook.site for testing API Events, but there are other options.

Open Dental hosts a test database for developers to test against. The base URL is the same endpoint listed above.

See the Authorization section above for the test credentials.

Retrieving Aging Data

These steps work for very large databases and should be taken to retrieve Aging data.

Within Open Dental:

1. Ensure the Open Dental Service is running.
2. Ensure the preference Automated Aging Runtime has a time entered.

Via the API:

1. Use GET preferences to retrieve the date and time aging last ran.
• Supplying PrefName=DateLastAging returns the date aging ran.
• Supplying PrefName=AgingServiceTimeDue returns the time aging ran. (Ignore the date component.)
2. If DateLastAging has not been updated, wait until after the time in AgingServiceTimeDue has passed before moving forward.
3. Use PUT queries/ShortQuery to query the patient table for the guarantors that have balances.
• Optional: Providing a clinicNum reduces execution time.
• Example query:

  SELECT patnum, estbalance, bal_0_30, bal_31_60, bal_61_90, balover90, insest, baltotal FROM patient WHERE patnum=guarantor and clinicnum=@ClinicNum AND ( estbalance>0 OR bal_0_30>0 OR bal_31_60>0 OR bal_61_90>0 OR balover90>0 OR insest>0 OR baltotal>0)

To get aging data as of a date other than today (not recommended), there are two options:

1. Use GET reports/Aging. This endpoint does not run in a timely fashion on larger databases.
2. For larger databases, set up an SFTP server and use Query Example 1655.