This is the kitchen sink: it is designed to develop sophisticated applications that directly and natively interact with the IPCortex CS. You could, for example, build your own custom application like keevio (we do in fact - keevio is implemented only using this public API).
Using the Full API you can initiate calls directly (in compatible browsers) using WebRTC, and have your application interact with incoming calls and chat messages.
CAN: Do just about anything on behalf of a user: initiating and terminating phone calls; starting chats; reading and writing chat messages; and initiating multimedia sessions in the browser. Really, it can do anything keevio can do and more, limited only by your imagination.
CAN'T: There's very little it can't do! However there are some practical costs to this, aside from the obvious extra complexity you need to grok. The full API interacts with the IPCortex CS and builds up substantial client side state on initialisation of its JS library and then maintains this asynchronously through WebSocket listeners. This is designed for responsive long running client applications, or indeed server applications via node.js, but we don't recommend using it within short lived web pages. If you are frequently reloading your application pages and re-initialising the API then this is going to be fairly resource intensive both within your client environment and on the IPCortex CS.
Authentication: Must use session authentication via an interactive API username and password.
This is a reduced footprint version of the Full API, intended to implement simple screen popping and call monitoring only. It is intended to be a pluggable replacement for the full Javascript API, but the vast majority of its features will intentionally not function - although this will happen in a clean way.
- CAN: Live monitor, initiate and terminate calls. It has a smaller footprint and much lower server load in applications that need to be able to re-load page(s) regularly.
- CAN'T: Do most API functions described in this documentation - although it should pretend very successfully to do everything it is asked and politely decline if necessary. It intentionally does not load things like usernames, device names and extension names in order to reduce refresh load, and only provides information on the logged-in user's device(s).
- Authentication: Must use session authentication via an interactive API username and password.
Used for stateless transactions which trigger events or query data on a one-shot basis. It can be used from interactive or non-interactive applications to do things such as making a phone call to a number using a separate keevio phone; starting a chat session in keevio with someone; querying stats; or making admin changes on the IPCortex Communication System (CS).
- CAN: Trigger interactions using keevio or a desk phone, query data, and make configuration changes.
- CAN'T: Embed full keevio functionality in your own application i.e. it can't initiate WebRTC audio or video directly within your own application or send and receive individual chat messages from your application, for example.
- Authentication: Can use session authentication cookies via interactive user login, or non-interactive API keys.
