The Xelion API also supports WebSockets. Currently WebSockets are used to send notifications to the WebSocket clients.
For example, when a new call is started and can be shown on the active call list. Without a WebSocket connection you will have to poll the new information from the API, which can be heavy for the server and many times will return the same result. It’s also important to know, that calling a specific API request to many times can result in a block for the specific client. In this document the WebSocket connection will be explained further.

Checkout the websocket Changelog regulary for changes in the Xelion websockets.

A WebSocket connection can be requested when an API session is started.
With the call WebSocket a WebSocket connection URL can be requested.

When a WebSocket URL is requested and an URL is returned, this URL can be used to open the actual WebSocket connection.
Start a WebSoket with this URL. When the connection is accepted, the connection stays open, otherwise the connection is closed directly with an error message.
After the WebSocket connection is openened, notification messages can be received over this connection.
Before the notifications are received you will have to subscribe to specific notifications (check out the next chapter).

A test message can be send to the websocket. When this message is received you will receive the exact same message back from the websocket server.
The testmessage should be formatted as an Message with the messageType test.

When a WebSocket connection is created, you will have to subscribe to the notifications that you want to receive over this connection.
Send a message of the type Notification Request to subscribe or unsubscribe to the notification.
It is also possible to subscribe to multiple notifications in 1 call by sending a message of the type Multi Notification Request.

When a WebSocket is subscribed to a notification, these are send with WebSocket messages.
WebSocket messages are always of the type Message, when this message is a notification the subclass Notification is send.

A notification object has 2 parts:
- The notification type value represents the type of notifiation, the notification types are described in the Notification Type Enumeration, in this enumeration the notification object type is also described.
- The notification part is the Notification Object that represents the actual notification that needs to be processed. Every type of notification needs a different process which is desribed in the Notification Object subclass documentation.

In the WebSocket interface ping/pong messages are added to checkout if the WebSocket connection is still active. Xelion sends a ping heartbeat message every 15 minutes. The client should respond on this message by sending a pong heartbeat back to the WebSocket server with exactly the same payload data as the ping message. When there is no response after sending 3 heartbeats the session is closed and needs to be reopened. This technique is used to make sure no sessions are open while the client is not online.

Check out the examples to see some websocket clients that are based on the current API and WebSocket technology.