We often take for granted the interconnectedness of our software-oriented world.  How do maps show up in my calendar application? Why can I use my Google login to access my Nike+ account? How do my video recordings get linked to events in my access control system?  

All of these different products from different providers link up and work together through application programming interfaces, more commonly known as APIs. APIs fuel integrations between access control systems and a vast variety of adjacent applications, from identity management to booking services for yoga classes. 

You can think of an API as a dating service for software applications. Just as people use dating services to help them break down barriers to creating lasting relationships, software applications with the desire to connect to one another use APIs to streamline their courtship. 

APIs allow developers to expose their programs’ internal functions in a limited fashion.  Developers control and define the ground rules for requesting services from another program. Think of it as application A providing half a bridge and application B providing the other half.  Then a developer completes  the connection between the two bridges. That is much easier than building the whole bridge by yourself.

In this way, APIs are similar to dating services that provide users basic profiles of potential partners that allow them to determine if they are compatible before they invest the time in a date. When you connect two software developers with an API, they will quickly determine if they are compatible and either map out an integration, or move on. 

Without an API, the process of joining applications is more like a high school dance.  If they do connect, its likely to be a clumsy embrace with each party unsure of the others methods and intent, leading to awkward, short-lived relationships and ugly breakups.   

In many cases, breakups happen when one application builds the whole bridge to another application that made no similar investment. Other times a developer uses an API on one side and then a custom, one-time integration on the other.  The unequal relationship in both of these examples creates the conditions that can result in the custom bridge falling into disrepair.  

By comparison, APIs require commitment to start and to sustain. By building their half of the API bridge, each partner is pledging to keep their part of the bridge intact and up to date. This situation is self-policing, because building and maintaining one half of a bridge is much easier than building many different complete bridges.

Security professionals enjoy true benefits from using integrations developed on standard APIs at both ends of the bridge. After all, you’re not interested in the bridge, you’re interested in the value provided by crossing it.

Like in any relationship, there are some bad actors in the world of APIs.  APIs can be discontinued with little notice, poorly documented or thinly supported.  But the vast majority of organizations using APIs for integrations understand that the number of potential integration partners and unique applications is skyrocketing, and that the only way to keep up is to commit to building and maintaining strong APIs.   Ultimately this is great news for you, the consumer.