If your IT team can handle the Twitter API or Facebook API, it should be able to grasp and use external communication...
APIs. When you want to embed a communications API into your business applications to streamline workflows, the process is not much different than adding a Google Maps API or consuming any other type of application programming interface.
However, when using communication APIs, keep in mind their asynchronous nature.
For example, when you dial a call, multiple steps need to occur. Each step adds to the forward momentum of the action. This forward momentum can be dropped at any point by various types of errors.
To illustrate this point, search for "call state machine" in a Google image search, and see what you get. I'll wait here for you.
Did you notice the many bubbles and arrows moving from state to state? You should expect some of these states. Oftentimes, your integration code will require a set of calls that occur asynchronously. For instance, you call an API, wait for it to return at some point via a callback or another event, and then continue from there.
For many developers, this type of programming and thinking is unusual, but it's necessary when dealing with communications.
End-user behavior unpredictable
In this video, evaluate communication API providers and choose the one that fits your needs.
The second facet of communication APIs is they work in front of people. For an incoming call, for instance, you need to get a notice in front of the user and wait for the user to answer or reject the call. As another example, if you need to upgrade a chat to a video call, you need to ask the user to agree.
This feature adds a level of complexity on top of the asynchronous nature of communication APIs because users are unpredictable. Users, for instance, can decide to answer or reject calls, or ignore them altogether. Or, did the user press the answer button after the call timed out and disconnected?
Communication APIs add edge cases that might not be obvious if you haven't dealt with voice over IP in the past.
On premises vs. cloud and the network effect
Working with communication APIs that operate on premises via a local PBX, for example, is different than using a cloud-based communications API. A cloud-based service is easier to use, but may require some tweaking of the firewall settings in the enterprise. An on-premises communications API usually takes longer to develop, since it requires more configurations and preparations.
If you opt for an on-premises unified communications service, your IT team needs to know how to use these APIs. But that level of knowledge is perhaps not necessary for a cloud-based communications API.
Last, but not least, IT needs to understand how these new communication mechanisms affect the enterprise network. For instance, do you need to configure the firewall to let media flow properly? Do you need to prioritize media packets over other traffic? What is the expected traffic and at what bitrates?
When dealing with a communications API, you need to make sure IT understands the topic sufficiently. This understanding is necessary if you work with the API yourself, or even if you outsource the development to external vendors.
Communication bundles simplify application development.
Track some trends in the communications API market.
APIs help enterprises integrate communication into workflows.