Bulk update comm log

[saskia]

Hey folks - wondering if it's possible to do a bulk update on the comm logs? (https://www.opendental.com/site/apicommlogs.html) At times we send out hundreds of messages on behalf of our client and looking to write those back, but we'd quickly be hitting out throttle limit (1 request per second if memory serves?) so hoping we can batch a bunch into one call, rather than one per patient per comm method.

Thanks!

[DerekR]

Open Dental software does not allow for mass updates except in very specific situations (such as completing procedures on a completed appointment). The API behaves similarly.

[saskia]

I feared that was the case. We'll have to build in our own delay to ensure we don't get throttled when we're trying to post hundreds of comm logs when we do a batch send. A real bummer, this is definitely an API where being able to bulk update would be very useful and reduce load for both sides.

[justine]

I feared that was the case. We'll have to build in our own delay to ensure we don't get throttled when we're trying to post hundreds of comm logs when we do a batch send. A real bummer, this is definitely an API where being able to bulk update would be very useful and reduce load for both sides.

Please revisit API Implementation documentation, specifically Throttling. Every single remote API request experiences throttling. You building your own delay would essentially result in you throttling yourself.

You may also consider utilizing the API Service, where API results are increased to 1000 items and requests experience no throttling.

Thanks!

[saskia]

We're seeing requests timeout and have been assuming that's OD throttling us - is this not the case? From what I can see in the documentation, it's 1 request per second - what happens when we go over that? We want to make sure the data we're trying to write back gets written back and we don't have to keep coming back at later stages to do so because the initial request timed out. Thanks.

[justine]

We're seeing requests timeout and have been assuming that's OD throttling us - is this not the case? From what I can see in the documentation, it's 1 request per second - what happens when we go over that? We want to make sure the data we're trying to write back gets written back and we don't have to keep coming back at later stages to do so because the initial request timed out. Thanks.

No. Throttling is not a timeout. OD API experienced slowness approximately 7 hours ago. This has been addressed as of 9:30AM PDT.

If you go over 1 request per second, the requests stack and are processed in the order in which they are received. It's important to note that throttling occurs on a per customer key basis, not a per developer key basis.

[saskia]

Gotcha - so as long as we don't care that it may take a few minutes, we can just send a large amount of requests, and they'll simply be addressed in due course? Clients could be sending out emails for all patients who have a balance, which can often be 200+, but no one is concerned if it takes a few minutes for the comm log to reflect that in OpenDental.

Outside of an OD issue, what could be causing timeouts? We've been seeing it intermittently with one client in particular (on payment write back), though this morning we had a few, but sounds like it did coincide with the timing you mention.

Thanks!

[SLeon]

Yes, you can send your API requests en masse and they will be processed, in the order in which they are received, and throttled on our end. Depending on how you design your application, you may implement synchronous or asynchronous calls to suit your needs. Your use case of "sending out" communications could be done async, for example, if the dental office user doesn't need to interact with it after sending.

The most common culprits of API request timeouts are:

• Using the Queries resource on a unoptimized query that takes longer than 60 seconds to execute.
• The dental office database is otherwise locked/under heavy load
• Issue with the office's eConnector. Any interruption in it running properly (server is offline, database is unavailable) would impact API requests
• Network connectivity issues within the dental office (poor or no internet access)

However, if most API methods are executing in normal timeframes, and it is just specific endpoints (eg Payments POST) that are slow, it is unlikely a connectivity issue. When the affected dental office makes payments through the UI in Open Dental (not via API), do they experience slowness in that workflow?