Smartswitch contains several Application Programming Interfaces (API).
Each of these interfaces was created for specific purposes.
When choosing an interface, we recommend that you familiarize yourself with all the available interfaces, as well as the goals they serve.
Interfaces are listed in order of increasing complexity of use and entry threshold for the programmer.
We recommend switching to a more complex interface only if a less complex interface does not allow you to solve your problem.


This interface allows third-party applications to communicate with Smartswitch with minimal involvement into Smartswitch logic and structure.
The purpose of creating the REST interface is to allow third-party applications to communicate with Smartswitch using a minimalistic API, with a minimum number of functions and arguments.
Also, third-party systems that support the REST protocol can theoretically connect to Smartswitch after configuration, without additional modification, in case if they have enough options to configure the integration.
So, it is possible to implement a connection without the involvement of a programmer.

The disadvantage of REST is that with increasing connectivity between objects (for example, we get one object, then we get another related object from it, etc.), a number of problems arise:

Therefore, we use REST only for primitive operations.
For the Smartswitch object-oriented model, we use the ICE interface (see below), which elegantly solves the above problems.

Pros of the REST interface: Cons of the REST interface: The REST interface is suitable for linking Smartswitch with:

For details, see REST API.


This interface allows third-party applications to communicate more closely with Smartswitch.
The interface is an object-oriented model of Smartswitch.
The goal of creating the ICE interface was to enable third-party applications to communicate with Smartswitch using a complex API,
with a large number of functions, arguments, and mutual dependencies.
You need to involve a programmer to connect third-party applications through this interface.

The ICE interface contains all the APIs present in the REST interface.
However, besides this, the ICE interface contains many APIs that are not found in the REST interface.
Thus, the ICE interface can always be used instead of the REST interface.
However, the converse is not true.

Pros of the ICE interface: Cons of the ICE interface: The ICE interface is suitable for development:

For details, see ICE API.


This is the lowest-level interface that allows third-party applications to access the details of making calls through Smartswitch.
It is not a replacement for the REST or ICE API, but complements them in cases when you need more control over the call or need to obtain call status events.

When connecting third-party applications through this interface, you need to involve a programmer.
The exception is if you connect a third-party application that was created to connect to Asterisk.
In this case, you can replace Asterisk with Smartswitch, without modifying this third-party application.

The AMI interface is suitable for linking Smartswitch with:

For details, see AMI API

Русский перевод