It's as inevitable as death and taxes. At some point, previously stable APIs start to throw performance errors and generally degrade. This can manifest in a number of ways:
- The API starts to have more failures.
- There are more time outs.
- It gets slow for no apparent reason.
There are many reasons for this, from an inattentive dev group to older equipment being used - but the net result is the same. For us here at APIContext, it's interesting to see how our CASC (Cloud API Service Consistency) Score relates to a company's decision to depreciate the API (sunset the use of the API). Usually it's because a new one is coming, or they're killing the related service. We track how quality changes all the time, and those changes warned us of this example. 

Burying the Lede on Previously Stable APIs
We know from history that API owners can be poor at communicating changes in their APIs. Twitter, for example, is known for burying the lede concerning API changes at the bottom of otherwise unrelated updates. One client also completely changed their OAuth configuration without actually telling a single user of their APIs. It completely shut off a number of applications. With early warning you can know that something is coming to get you. Or at the very least, you'll know to contact your service provider for more data – before the dependent apps and services get shut off for good. One of the values of monitoring the APIs you are using in your connections is you can use something like our CASC score to warn you that something bad might be about to happen to something that you depend on as an organizations. Why not contact us about getting a CASC score for your APIs?

