New API

[jordansparks]

The new API is now functional. That doesn't mean it's been released yet, or that it's very good yet, but it is functional. We'll keep FHIR around, but this new one is where we will put all our effort. FHIR was simply too complicated. By starting over from scratch, we can make an API that people can actually use and that we can add features to much more quickly. For example, the objects and fields now correspond directly to tables and columns in our database. And it addresses issues that were lacking in our FHIR API, such as pagination and readable documentation. This will all be in Version 21.1. Documentation will be posted soon.

[sammyp42]

This is excellent news!

I have been creating my own APi for an internal web service and have hooked it to OD using a Plugin for more complex and update logic (to not break support rules).

Will the API be open source, or will it exclusively be hosted via proxy server?

Would be great if you gave both options (kinda like support model today). Then, we have option to roll our own service with the API (no API support), or pay for value add (secure proxy hosting, etc...).

[jordansparks]

For now, we are going to host it. I don't quite follow your suggestion about the alternative. The goal is to make it massively powerful. Even though the connections would go through us, we can still keep costs down by hole punching so that you and the customer are connected directly and the message itself doesn't go through us. But I don't think we would want third parties adding their own methods to the API. That would defeat the purpose of us managing the safety of each method.

[sammyp42]

I was thinking along the lines of potentially integrating the API with other services (for example, alternate methods of hosting the service), but could see why you would shy away from that. The use case I'm thinking of might not be practical either... just thinking out loud.

But to play devils advocate, I don't think anything prevents someone from releasing an open source NodeJS based REST API (along with a plug-in DLL to enable advanced functionality) ... of course on a "use at your own risk" basis.

[jordansparks]

Well, we'll have to do something about plugins eventually. We need to be able to vet them specifically to avoid the scenario you suggest. Plugins are to add UI elements or for supplemental database tables. They shouldn't be used for an end run around the prohibition against write queries. But first we need to make this API so attractive that nobody will want to bother with a plugin.

[acaziz]

Hello

I am just getting into creating a plugin. Are we still good to develop the plugin or wait till new API?

[jordansparks]

Just do the API. It's so much easier. Plugins are for when you want to make a whole new window in the UI that only talks to your own tables in the db and not any of the other tables. We'll eventually need to clamp down on queries from within plugins, so don't waste your time. Look at all the methods available in the API as we currently have it documented. Be sure to let us know about any methods that you need in the API, but do not see.

[sammyp42]

Is there any ETA for when anything related to this new API will be released? Any sort of documentation?

[acaziz]

I called OD office. It's at the bottom. https://www.opendental.com/manual/fhir.html

[cthulu]

I tried using it with my existing API token and my query string was the same as a few of the examples in the documentation, but it did not work. Do I need a new API token for it to work, or should the one I already have be ok?

[jordansparks]

Same token, but it will be a new URL. That detail is explained in the link above. Click on the PDF link on that page.