API For Client Keys?

[mandmdiet]

We're looking at doing further integration with the Open Dental API regarding client keys. Here are the two things we would like to do with this additional integration:

Read Key Metadata

Currently, if we want to know what version of Open Dental a user is on, we check the developer portal and look up that practice's key. This is a great way for us to know their version but is it possible to discover this information programmatically as well? We'd like to be able to enable or disable certain features in our application based on the Open Dental version of the client and we'd like a programmatic way to discover that.

Key Creation

We're planning on rolling our software out to several clients here pretty soon and it would be great if there were a way to request that a new key be created through some sort of API so that our users don't have to log in to the developer portal separately to do this.

Are either of these things already possible, or would it be possible to add these features? We could always implement it with screen scraping, so I don't see how it could pose any kind of security risk.

Thank you.

[SLeon]

Good afternoon,

The version the dental office is on is stored in the preference table as "ProgramVersion". You can use Preferences GET or Queries PUT ShortQuery to obtain this value. It will be in the form of #.#.#.0 (eg 23.3.9.0).

As far as generating keys, the current plan is to keep that to the Developer Portal to verify that it is the developer creating these keys. Could you please elaborate on "so that our users don't have to log in to the developer portal"? You, the developer, can create as many keys as you like and distribute them to your customers over time as you see fit. Only enabled and assigned keys are processed for billing. Some developers generate a dozen or so keys at a time and store them in their own database, to distribute to customers as needed.

[mandmdiet]

Could you please elaborate on "so that our users don't have to log in to the developer portal"?

Sure, we have an internal IT staff that will be on-boarding new offices to our software. To do this, they log into an admin portal for our software and enter some information about the new office. Things like clearinghouse user credentials, internal office IDs, the office name and the new user for the office. As part of that, a new Open Dental key needs to be created, associated with this new office record in our software and given to our support staff for configuration in the office's Open Dental instance. We could give our IT personnel access to the developer portal so that they can generate their own keys and provide them in our software's admin portal but it would be a bit easier if we just generate the keys programmatically and then provide it to our users at that time.

[SLeon]

Would it be possible in that workflow to keep a list of unassigned API keys handy (internally) that your staff can distribute to the customer?

[mandmdiet]

Yes we can do that. One issue I see with that is that if we generate several ahead of time and put it on a list to use later and then someone logs into the Open Dental Developer Portal, sees an unused key, and uses it, then later the key on the list doesn't work for a new office setup.

Still, we can follow this process, it just has some drawbacks.