APIs are the most frequently misunderstood and over-hyped aspects of physical security. While APIs can provide great benefits, using them is much more complex than often mentioned.

   
The goal of APIs in physical security is to allow different applications to work together. Integrating a DVR/NVR with an access control system; integrating an alarm system with a central monitoring system; integrating an IP cameras or analytics with an NVR; building a PSIM system that integrates with all security systems are just a few examples of an API in physical security.

   
You most commonly hear APIs discussed in pre-sales situations where a customer or integrator asks a vendor: “Does your system work with ‘X’?” where X could be any number of security systems by any number of manufacturers. The routine answer is: “Sure, we have an API.” For as long as I have been in security, I have been hearing this response. This is the most dangerous and misleading statement in all of physical security. Because it is so common and so dangerous, it is a great place to start reviewing APIs.

Lesson #1:

There is no such thing as ‘an’ API. Numerous APIs exist. In larger systems, hundreds of APIs exist. Generally, there is an API for each function in a system. Want to watch live video? Then use the live video API. Want to change the time? Then use the time change API. Want to increase the frame rate for recording? Then use the recording frame rate API, etc.

Lesson #2:

Not all functions have an API available. Let’s say you need to get a list of all health alerts from another application. This application may have an API, but not a specific API for sending health alerts. As you can imagine, because most systems today have hundreds of functions, it is common that dozens of these functions are not accessible via an API.

Lesson #3:

Having an API does not mean it will work with your system. Let’s say you have Genetec for your NVR and Software House for your access control. Both of these companies certainly have APIs, but there is no guarantee that these two products will work together. Both companies having APIs is a pre-requisite for integration, but it is not sufficient. At the very least, both of these companies need to work together to ensure the integration works reliably. Many companies certify its API works with partners, but frequently your specific product combination will not be included.

Lesson #4:

Integrating a system takes time. Vendors often claim a few weeks for integration. This is possible, but often technical details are more difficult, which can take significantly longer to tweak. Be careful in the time and dollar amount you commit for such projects. This is the type of risk that is often unknown and unknowable until you dig into the technical details about how each vendor implements their APIs. Generally, these projects are ultimately successful, but the time and cost can vary.

Lesson #5:

API changes can break you. Just like a product, over time, APIs change. The difference is with APIs is that their change can break your system. Reasons for change include eliminating bugs, enhancing performance and adding in new functionalities. Other systems depend on
those APIs.

   
Let’s say your system works with Vendor B version 3.1. Now let’s say Vendor B comes out with version 3.2, but this version breaks the API. In other words, the new version is not backwards compatible with the old version. Your system could suddenly stop working with Vendor B if you upgrade Vendor B to version 3.2. The result is your security command center no longer displays video or access, or which upgrade was made.

Lesson #6:

You are stuck with what the API does. Unless you are a very large customer, you are stuck with whatever the API does, in whatever way it does it. Often, for what you need, this works out fine. However, if you need some change for a specific use, this can be hard to accomplish. Make sure someone on your technical team knows specifically what the API can and cannot do, so you can anticipate any potential problems up front. If a change needs to be made, the change will usually take a lot of time and testing.

KNOW YOUR API

SIDEBAR: Video in Hands of Others

There has so much written about the convergence of security and IT, but there’s another possibly more importance going on. Security video systems are playing double and triple duty tied to financial systems, operations, training and management overseeing.

   
Technology is especially evolving through software and third-party services. For the past fives years or so, retail companies such as McDonalds and Walgreens, have helped pioneered in ways beyond traditional security video.

   
It turns out to be a business world.

   
One example: Envysion, a firm in Web-based video management, has new technology that gives operators the insights to improve business performance in every location, every day. The Managed Video as a Service (MVaaS) is based on the Software as a Service (SaaS) model of software deployment, where software is hosted as a service provided to customers across the Internet. Like other SaaS applications, it eliminates software upgrade and version control challenges while protecting customers against technology obsolescence.

   
Using SaaS, in emerging services like this one, chief security officers and management executives should gain. 

• Entirely Web-based user interface provides easy access to video in any location from anywhere in the world.
• SaaS model eliminates much of the networking complexity and IT requirements at each remote location.
• Customers benefit from improvements in technology and capabilities without having to manage upgrades or version control.
• Centralization of user and recorder management allows administrators to easily manage access for many users across a large number of locations.
• Real-time monitoring of all devices (recorders and cameras) ensures customers’ systems are fully operational.