Let’s Talk About APIs Series
Part 2: The Yin and Yang of APIs and Data Feeds

This is the second of a multi-part series on APIs with CLIEDIS. Read Part 1: Defining ‘API’ here.

In Chinese philosophy, ‘yin yang’ is the concept of duality forming a whole. It describes how seemingly opposite or contrary forces may actually be complementary, interconnected, and interdependent.

These words describe the relationship between APIs and data feeds.

With data feeds, information is generated, sent, and processed on regular intervals. The data is stored locally in the system of the receiver. This allows you to query and analyze the data. You can trigger notifications and actions based on what you received. To do reporting, you need locally stored data.
In contrast, APIs provide behind the scenes, real-time connectivity between systems. Information is not sent to you on regular intervals nor is it stored locally. Instead, you make requests from the source when needed.

For an API to work, you need data. At an ATM, the information retrieved from your card is that data. In insurance, it is the policy number and other identifying information in your records. If you don’t even have a record of the policy why would you ask for more information about it? That stored record is fundamental to an API process.

At CLIEDIS, our focus has been on the implementation of three main CITS data feeds: Application Notification, Pending Status, and Book of Business. These three feeds work together to establish the base within the system. They ensure that the distributor has current records of all the business for which they are responsible.

That base is not only necessary for reporting, it is needed to be able to do anything else. APIs use the data you already have to take action, whether it is to ask for more information or perform critical tasks.

At CLIEDIS, we looked across many member requests to augment the base information. Some requests were best served with APIs, some as data feeds, some as both.

For instance, commissions lend themselves to feeds quite nicely. The information is generated at regular intervals and you want the data stored so you can report on it. Real-time policy values, on the other hand, are best with an API. For a UL policy, the value is only as current as to when the data was generated. If you want the current value it needs to happen real-time, not last week.  Images to replace paper documents may best be served as a combination. A feed can tell you what documents are available for a policy. For some document types, like a billing statement, you may simply want access to it in the event of a problem. If you know the document is available, an API can be used to access it when necessary.

Without the data feeds you would have no base to build on. APIs can then take that data to the next level to automate your business. APIs augment feeds, not replace them.  Yin and Yang.

_______________________________________________________

Next up in this series: Why API Standards. Stay tuned!

In June 2018, CLIEDIS announced a major effort to develop API standards for the insurance industry. To learn more about this initiative, come to our next webinar on August 22^nd.

For more information on the API work being done by CLIEDIS, please contact Tana Sabatino, Implementation Services Specialist at CLIEDIS: tsabatino@cliedis.ca or, Darlys Corbitt, Executive Director at CLIEDIS: dcorbitt@cliedis.ca.

Tana Sabatino

Phone: 415-431-6666

Darlys Corbitt
Executive Director
CLIEDIS
Email: dcorbitt@cliedis.ca
Phone: 519-702-7643