Understanding API - Turing Insurance

Scope/Platform

Scope: A guide for understanding Application Programming Interfaces (APIs)

Platform: The following platforms and applications will be touched on.

APIs (in concept and practice)
ClaimsRadar
Salesforce

Intro

This article is a guide for understanding Application Programming Interfaces, how they function, and where Help Desk Technicians may encounter them. APIs can and will fail. Requests can be delayed; data delivery can be missed. It is on us as Help Desk Technicians to troubleshoot these issues, which we will cover in a future article.

Who is this for?

This article is aimed at an audience of Help Desk Technicians, and other departments who troubleshoot APIs, but generally do not program them. It assumes its reader has a general understanding of usernames, permissions, and workflows.

Prerequisites

As this article will be talking about some Turing Insurance systems, readers will require access and exposure to unique Turing Insurance applications such as ClaimsRadar and Salesforce.

What is an API?

APIs (Application Programming Interfaces) are methods and tools that allow for communication between applications or computers. For example: ClaimsRadar sends data regarding customer information and status to Salesforce. This process is automatic, and (mostly) seamless.

Think of it like this.

Salesforce requests data regarding a client
The API sends this request to ClaimsRadar.
ClaimsRadar processes this request and hands the data back to the API.
The API delivers the data back to Salesforce.

Request > Send > Process > Deliver is the core loop of the API.

Why APIs are necessary

APIs are the backbone of modern digital infrastructure. While APIs are unique to the application it was created for, any application can communicate with said API to send a request to the application if it has the appropriate access and permissions. This is how arrival and departure times for the MTA subway system can be included in something like Google Maps, or how an application like Slice can show you the price of pizza at multiple restaurants.

API architectures and types

APIs are generally differentiated by architecture and type. We will focus on just one architecture, called REST, which will be the bulk of your encounters with APIs on the job.

REST (Representational State Transfer)

A method for apps to communicate via various web protocols such as HTTP
Turing Insurance internal APIs are generally REST

REST APIs rely on a few key functions:

GET - pull information
PUT - update current information
POST - create new information
DELETE - remove information

ClaimsRadar's API is an excellent example of a Private / Internal API. It is owned by us, and used by us almost exclusively.

For more information on API architecture and types, please look to the sources posted below.

Common API Failure Points and Escalation Triggers

Like any system, APIs can fail. These failures will look like missing data, record synchronization issues, and late data arrival.

Missing Data
A user calls in stating that claim updates from ClaimsRadar have not arrived in Salesforce. They also state that new claims are not arriving as well. In this case, we must: A. Determine when this issue began. B. Confirm if the user has tried closing and reopening the page. C. Find out how many in said department are affected. D. Fully conclude what else might be missing. E. Document all error messages.

Escalation Trigger: If the issue is affecting multiple people, document all the above data points and escalate.

Data viewing issues.
The Actuarial Team emails the Help Desk complaining that they cannot view claims records with ClaimsRadar, but that the Underwriting Team can. While this may point to a system outage, it often does not. Our job here is to: A. Determine who exactly is affected. B. Confirm exactly what they are trying to access. C. Check their security group access in Active Directory. D. Confirm if they have been able to access this data before.

Escalation Trigger: If the users of the department should have access based on their security groups and previous access, escalate.

Duplicate Data
A user from Underwriting calls in reporting that claims are duplicating themselves in Salesforce. Only some claims are affected, not all. They are able to delete the extra copies, but want the issue resolved. Here is what we can do: A. Figure out who is affected. B. Compare timestamps on the claims in Salesforce. Look for patterns. C. Determine the origin point of the duplicate claims.

Escalation Trigger: If you can confirm that the person at the origin point is not submitting claims twice on accident, gather the claim record IDs and escalate.

Conclusion

APIs are a core backbone to our IT infrastructure. While we do not deal with APIs directly, we are the first line of defense when issues occur. Our job remains to determine scope, gather information, and determine if the issue is really with the API, or something else.