Page 1 of 1
API Definitions - PUT
Posted: Thu Apr 16, 2026 1:40 pm
by rgibbons
Hello,
I see the API Definitions for GET and POST (Get and Create),
https://opendental.com/site/apidefinitions.html
I was wondering if y'all could expand this to PUT as well (Update). We are needing it to be able to update the names of Definitions (in this specific case in the Adj Types Category) on scale.
Thanks,
rgibbons
Re: API Definitions - PUT
Posted: Thu Apr 16, 2026 3:03 pm
by justine
rgibbons wrote: Thu Apr 16, 2026 1:40 pm
Hello,
I see the API Definitions for GET and POST (Get and Create),
https://opendental.com/site/apidefinitions.html
I was wondering if y'all could expand this to PUT as well (Update). We are needing it to be able to update the names of Definitions (in this specific case in the Adj Types Category) on scale.
Thanks,
rgibbons
Hello rgibbons,
We don't currently support PUT for definitions, and we're not planning to add it at this time.
Definitions are intended to be created and referenced, not updated via the API. Allowing changes via the API could introduce inconsistencies with existing entries that depend upon them and can cause confusion when multiple third party API developers are involved.
Instead, you can create new definitions using POST.
Thanks!
Re: API Definitions - PUT
Posted: Wed Apr 29, 2026 11:30 am
by rgibbons
Hi Justine,
I appreciate the context regarding the current limitations. However, we’d like to strongly urge the team to reconsider adding PUT support for Definitions for a few reasons.
First, data hygiene. Relying solely on POST to "update" information creates redundant, duplicate entries. We already have a cluttered database of entries with a trailing space, a small typo as they enter across dozens of locations, and general confusion around the inconsistency that you mentioned, as old definitions remain active and selectable alongside the new ones.
Second, vendors should ideally be built to reference a unique ID rather than a mutable display name. If a third-party application breaks because a definition name was updated, that points to a lack of resilience in their implementation. The API’s evolution shouldn't be constrained by the potential for brittle code in other integrations.
Third, this isn't just a niche requirement for us. Any other practices looking to standardize their data, fix typos, or rename Adj Types to match updated accounting practices at scale would benefit from this. PUT helps keep everything professional and organized across locations for DSOs and other entities that require standardization.
Frankly, we are trying to adjust one of two things, either the ItemName field, or the IsHidden field, so that we can fix them, or "remove" them from the list via the API, the IsHidden field being the easiest.
Thanks for your help,
rgibbons
Re: API Definitions - PUT
Posted: Thu Apr 30, 2026 3:23 pm
by justine
rgibbons wrote: Wed Apr 29, 2026 11:30 am
Hi Justine,
I appreciate the context regarding the current limitations. However, we’d like to strongly urge the team to reconsider adding PUT support for Definitions for a few reasons.
First, data hygiene. Relying solely on POST to "update" information creates redundant, duplicate entries. We already have a cluttered database of entries with a trailing space, a small typo as they enter across dozens of locations, and general confusion around the inconsistency that you mentioned, as old definitions remain active and selectable alongside the new ones.
Second, vendors should ideally be built to reference a unique ID rather than a mutable display name. If a third-party application breaks because a definition name was updated, that points to a lack of resilience in their implementation. The API’s evolution shouldn't be constrained by the potential for brittle code in other integrations.
Third, this isn't just a niche requirement for us. Any other practices looking to standardize their data, fix typos, or rename Adj Types to match updated accounting practices at scale would benefit from this. PUT helps keep everything professional and organized across locations for DSOs and other entities that require standardization.
Frankly, we are trying to adjust one of two things, either the ItemName field, or the IsHidden field, so that we can fix them, or "remove" them from the list via the API, the IsHidden field being the easiest.
Thanks for your help,
rgibbons
Hello rgibbons,
I understand what you are saying, but we do not have plans to allow general Definition updates through the API at this time. The API does not own Definitions or any other table; the office does.
POST is not an update. It creates a new Definition. If an office has duplicate or typoed Definitions, that is a data-management issue within the office database. Definitions are shared reference data, and tables that use a Definition reference it by DefNum. Because of that, changing fields such as ItemName or ItemValue on an existing Definition can change the meaning of data that is already linked to that record.
We agree that standardization can be valuable when performed by the office/admin with full context. However, it is risky to allow third-party API vendors to rename or redefine shared Definitions that may already be used by Open Dental, staff workflows, reports, historical records, or other integrations.
That being said, we are willing to research the ability to hide or unhide an existing Definition through the API. This would not be a general-purpose Definition update, and it would not allow renaming or redefining existing Definitions. It would only apply to the IsHidden field, subject to the same rules Open Dental uses for Definitions, since some Definitions can be hidden and others cannot.
Thanks.