Page Contents
Requesting Other Data After Login
User To User Chat Typing Status
Loading Previous User To User Chat Lines
Sending A Message To All Connected Users
Changing The Status For Another User
When The WhosOn Server Closes Your Connection
Leaving The Chat After Transfer
M1,M0,MC1,MC0 - Typing Status (Event)
MissedChatResponding (Command)
MissedChatRespondingCancel (Command)
CannedResponseUpdate (Command)
CannedResponseDelete (Command)
Getting Current Visitor Totals Only
Enabling Current Visitor Totals Events
tartCurrentVisitorTotalsEvents (Command)
StopCurrentVisitorTotalsEvents (Command)
Server Visitor Event Throttling
The Client API is designed to create desktop, product embedded or browser-based WhosOn Operator Client applications or to add WhosOn Operator functionality to existing applications. Using Client API, it is possible to create your own WhosOn Operator Client applications using any developer platform that supports WebSockets.
The WebSocket Client interface uses port 8013 by default. The port can be changed using the WhosOn Service Manager. The WebSocket interface only accepts connections from IP addresses in the WhosOn Server Whitelist, since it is designed to be used via a secure Web Server proxy to the WhosOn Server.
Regardless of how you use the Client API, the standard WhosOn Operator Client can still be used. You can use the WhosOn Client in combination with any custom client applications you create or use your own exclusively.
An API key must be supplied with the Login command. Please contact Parker Software to obtain your API key before you start development against the Client API.
Connect a WebSocket on URL ws://{server}:{port} (or wss://{server}:{port} for a secure connection). Replace {server} with the IP address of the WhosOn Server or the Web Server if connecting via a proxy.
Important: WebSocket connections should always be secure (wss://). If you are connecting via a proxy then the web server will need a SSL Certificate. The WhosOn Server does not - since traffic between the proxy and WhosOn will be internal. If connecting to WhosOn directly then the WhosOn Server must be assigned a certificate and the 'Secure' setting of the Client WebSocket must be enabled.
Once a WebSocket connection is established it should remain open for the duration of the Client session.
UTF8 encoding should be used for sending & receiving.
JSON text is used for all messages.
All commands sent to the WhosOn Server have the following format:
The commandname is the name of the command to send to the WhosOn Server. Command names are not case
sensitive. Parameters contains a list of parameters (if any) associated with the command. All parameters are case
sensitive strings. If there are no parameters for a command send "Parameters": null
The Parameters list must be ordered correctly for the specific command.
Example:
Any numeric parameters should still be passed as strings. Any date parameters should be passed as strings in yyyy-mm-dd format.
The WhosOn Server will send data to the client as events occur. This will not only be in response to commands sent, but also when events happen (Eg: A chat request or another user changing their status). Your client application should monitor for events received and process each one accordingly.
All events received are in the following format:
Where eventname is the name of the WhosOn Server Event. The header property headerdata may contain additional parameters associated with the event, or it will be null.
The data property will either be a single string, null or an object (or list of objects).
Example:
All event data sent by the WhosOn Server to your client connection will only contain data relevant to your connected user - based on the user's access rights & assigned sites. It is not possible to request or receive data outside of the connected user's scope.
Your client must login before it can send other commands or receive events. Send the Login command:
The authenticationstring is the WhosOn Server authentication string. It must match the server authentication string setting.
The fullname is the users' full name. This is optional. If blank or the 'Can Change Own Name On Login' user right is false then the users full name from their user record will be used. This also applies to dept and phone.
version can be a version indicator of your client app.
status is the initial status the client user should be set to (0=Online, 1=Busy, 2=BRB, 3=Away).
lang is the user's two letter language code - if blank the language assigned to the user record is used.
platform is a string showing the client platform (e.g.: 'WebClient').
apikey is your API key. You must obtain your API key from Parker Software. The supplied API key must be valid. Client IP addresses will be blacklisted on repeated login attempts with an invalid API key.
If the login in accepted, you will receive the connected event. Header will contain your Connection ID.
If the login is not accepted, your client will receive:
Data will contain the reason for the login failure.
Once logged in you should not send the Login command again for the current session.
Normally clients using the WebSocket interface would connect using a secure WebSocket via IIS on port 443 (rather than a direct connection to the WhosOn Server). The 'X-Forward-For' header value will override the WebSocket Client IP if it exists. Client IP addresses are recorded in the UserLog table for auditing.
The Client IP is checked against the global blacklist and temporary backlist on connection. Clients that send invalid commands or have multiple failed login attempts will be temporarily blacklisted. The temporary blacklist settings are configured using the WhosOn Service Manager. The Service Manager can also be used to clear the temporary blacklist.
WebSocket connection attempts from blacklisted Client IP's will be immediately refused.
Following a successful login your client will receive the following events:
This is the first event your client will receive after a successful login. Header will contain your client Connection ID. The Connection ID is an integer number that is unique for your client's current connection. Data contains information about the WhosOn Server.
The PortalUrl contains a link to the WhosOn Settings Portal for the WhosOn Server you have connected to. This can be used to provide a link for client users to add or edit WhosOn Sites.
Data contains the User object which contains information about your connected user.
If the RequirePasswordReset is true in the user event, then your client should offer the user the option of changing their password. To change the password, send the ChangePassword command.
The MaxChats property contains the maximum concurrent chats that your client user can take (or zero for no limit). The WhosOn Server will stop sending new chat requests when this limit is reached (unless queuing overrides are setup).
The ClientOptions property contains any client options/settings. Client options can be set using the ClientOptions command. You can use this to store any arbitrary settings for your client application.
The Rights string contains the users access rights as follows (Y or N characters in the following positions):
If the Rights property contains a 'S' character, then the user is the System Administrator.
If the Rights property contains an 'I' character, then the user is marked as invisible and will not show to other users.
The WhosOn Server will allow/block access depending on the rights - however your client should also observe the rights and adjust the UI accordingly.
The Sites list contains a site item for each monitored site that the connected user has access to.
The WhosOn Server will also send a site event if a site is changed via the Settings Portal.
The following site properties are sent for each site in the sites event. Many more properties can be configured for sites using the WhosOn Settings Portal. The properties sent in the sites event are those that are useful for operator client applications.
| Property | Details |
|---|---|
| SiteKey | The unique number for the site. |
| Name | The name of the site as configured in WhosOn. |
| Domain | The domain name of the site as configured in WhosOn. |
| Paused | True if the site has been paused in WhosOn. |
| UTCBias | The UTC bias in seconds according to the timezone assigned to the site. |
| SLAWarnSeconds1 | The number of seconds after a chat request starts (before a user picks it up) before the first 'waiting' message is sent to the visitor. |
| SLAWarnSeconds2 | The number of seconds after a chat request starts (before a user picks it up) before the second 'waiting' message is sent to the visitor. |
| AllowEmoji | True if the user is allowed to send Emoji's during chat sessions. |
| AllowFileUpload | For visitor file uploads during chats: 0=No file upload allowed, 1=Allowed, 2=Allowed but only if user sends file upload request (FileRequest). |
| DisableFileSend | If True users should not be allowed to send files during chat sessions. |
| TranslationEnabled | True if Translation is active for the site. |
| CustomChatTab | True of a custom tab has been defined. If True you should add a Tab or view to chat session views and display the CustomChatTabUrl page in it. |
| CustomChatTabTitle | The title of the custom tab. |
| CustomChatTabUrl | The Url of the web page to display in the custom tab. |
| OnDemandFields | A list of On Demand Survey fields defined against the site. On demand fields can be requested during chat sessions. See: FieldRequest. |
| Invites | A list of Dynamic chat invites that can be sent to visitors. See: Invite. |
| ProspectTypes | A list of visitor prospect detection names defined for the site. The WhosOn Server flags visitors as 'Prospects' based on site defined Prospect Detection rules. The ProspectTypes property on VisitDetail objects gives the prospect number. If the ProspectTypes number on a visitor visitdetail is 1 then the prospect type name would be the 1st item in this list. |
| Alerts | A list of Site Entry Alerts defined for the site. Site entry alerts are used by the WhosOn Server to categorize visitors based on how they entered the site. The AlertNo property of *visitor events shows the Alert Number. |
| WrapUp | The chat 'wrapup' settings defined for the site. If Enabled is true you should offer then user the option selecting a Wrap Up value. If the Show property is 'Session End' then the wrapup should be shown when the chat closes. See: Chat Wrapup in the WhosOn Settings Portal. See Also: ChatWrapUpComplete. |
| CRM | The CRM Integration settings defined for the site. |
| Tags | Any chat tags defined for the site. See: ChatAddTags. |
Data contains a Clients list. The list has an item for each user currently connected to the WhosOn Server that the logged in user has access to. The Connection property is the Connection ID for that user session.
Normally your client will only receive a full list of connected users after login. From then on you will receive single clientevent events, as users login or change, and clientremove events as users disconnect.
Data contains a list of current chat sessions.
Your client will normally only receive a full list after login. From then on, your client will receive single chatchanged events as chats change (new chats, chat picked up by a user etc.) and chatclosed events as chats are removed.
Your client will receive all chats (that the logged in user has access to) in the chatting,chatchanged & chatclosed events. The TalkingToClientNo property contains the Connection ID of the client user that has picked up the chat. If this is zero, then the chat is available to pick up.
Data contains a list of pending Missed Chats (Missed chats that have not yet been responded and have not expired). Your client will not receive this event if the 'Can Respond To Missed Chats' user right is false.
The full list is only sent after login. After this individual missedchat events are sent when new missed chats are added, or existing ones responded to. A missedchatclosed event will be sent when a missed chat is removed (by another user responding to it or the missed chat expired).
You can request the detail of any missed chat by sending the GetPrevChat command.
Note: The WhosOn Server will mark any chat request as 'missed' where the visitor has started a chat (and completed the pre-chat survey) but no user picked up (even though users were available) and where the visitor leaves a message or callback request because no users were available.
Data will contain the INI string if a server-side client settings file has been created. This event will only be sent if the Client INI string exists. This Client INI is used to send custom settings to clients.
If the RequirePasswordReset property of the user event is true, then your client should offer the user the option of changing their password. To change the password, send the ChangePassword command.
The WhosOn Server will respond with either with a error event or a passwordchanged event.
Note: Passwords cannot contain characters with ASCII codes less than 32, quote or : (colon) characters. Passwords must meet the Minimum Password Length setting defined in WhosOn.
The ChangePassword command can be sent at any time once logged in.
The User event contains a ClientOptions property. This is a string value that you can use to store any arbitrary options/settings for your client application. The value is stored against the user record in the WhosOn Database. You can use any format for the string, for example:
Theme=Dark;AutoLogout=True;
To save/update the options string, use the ClientOptions command.
A single parameter is passed containing a string value holding the client options. You can use any formatting for the string. Once updated the value will be passed in subsequent User events for the user.
The WhosOn Server will send a msg event for any message that should be displayed to the client user. These are system/user related and designed to be shown to the client user.
The WhosOn Server may also send error messages. These should be displayed to the client user.
msg and error events could be received at any time during the client session.
'Access Denied' error messages can result in requesting data outside of the currently connected user's scope (eg: Requesting chat data for a chat belonging to a site that the user does not have access to). Too many 'Access Denied' errors will eventually result in the client being temporarily blacklisted.
After logging in you can request additional data from the WhosOn Server:
All of these are optional, however you should send the GetSkills,GetFiles & GetCannedResponses commands after login.
The GetSkills command can be used to get a list of all Skills (available to the connected user). The WhosOn Server will send the skills event.
Data contains a sorted list of skills available for all users and sites that the connected user has access to.
The GetFiles command can be used to get a list of all uploaded files (available to the connected user). The WhosOn Server will send the uploadedfiles event.
Data contains a list of uploaded files that are available for the connected user.
The HashedFileName property is unique to each file (even if multiple files have the same FileName). The URL contains a link to download the file - this is the URL sent to visitors during chat sessions.
If CreatedByUser is not blank, then the file was added by a user. The SiteKey will be zero for user uploaded files - since the file is available for all sites (that the CreatedByUser has access to).
If VisitorName is not blank, then the file was uploaded by a visitor during a chat session (and the VisitorUploaded property will be True). The SiteKey will contain the SiteKey of the Site.
The Size property is the file size in bytes.
The GetCannedResponses command can be used to get a list of all pre-defined Canned Responses (available to the connected user). The WhosOn Server will send the cannedresponses event.
Data contains a list of Canned Responses setup on the WhosOn Server that are available to the user. If SkillID = -1 then the response is available to the connected user only (My Canned Response). If SkillID <> -1 then the response is global (for all users that can see the sites in SiteKeys). SkillID is not used otherwise. The SiteKeys is a comma separated list of SiteKeys that the canned response can be used on.
Each Canned Response has an ID and ParentID allowing Canned Responses to be displayed in a tree structure. The Keywords property will contain the user entered keywords assigned to the response along with keywords automatically extracted from the response by WhosOn. You can use the keywords to aid in canned response searching during chat sessions.
The Attachments property will contain files attached to the response (separated by commas). These will correspond to the HashedFileName property of the files returned in the uploadedfiles event.
The GetUsers command can be used to get a list of all users (available to the connected user), regardless of if the users are logged in or not. The WhosOn Server will send the users event.
The GetUsers command is optional and only required if you wish to list all available users in your client rather than just currently connected users.
The Rights property contains the user access rights as described in User Rights.
The GetUserGroups command can be used to get a list of user groups (available to the connected user). The WhosOn Server will send the usergroups event.
The GetUserGroups command is optional and only required if you wish to show user group detail in your client.
The Rights property contains the user access rights as described in User Rights.
Users that are members of a group will have the GroupID property in the users event set to the Group ID.
The GetWorkPeriods command can be used to get a list of user work periods (available to the connected user). The WhosOn Server will send the workperiods event.
The GetWorkPeriods command is optional and only required if you wish to show user work period detail in your client.
Users that are members of a work period will have the WorkPeriodID property in the users event set to the Work Period ID.
You can send a message to any user in the Clients list. Send the SendToClient command:
The first parameter in the Connection ID of the client you want to send a message. The second in the message text. The message text can be a maximum 4000 characters. The other user will receive the fromclient event.
During a user-to-user chat you can send your client typing status. This will show in the other users chat window as an 'is typing' indicator.
To enable typing indicator, send the C1 command:
Parameters: Chat Number.
The other user will receive the C1 event.
To disable the typing indicator, send the C0 command:
Parameters: Chat Number.
The other user will receive the C0 event.
In your client application you need to enable a timer when the user presses a key in the chat message text box during user-to-user chats. If the timer was not already enabled – send the C1 command and enable the timer. If the timer is already enabled – record the time of the last keypress. In the timer event compare the last key press time with the current time and if a period of (say) 2 seconds has elapsed – send the C0 command and disable the timer.
Note: You do not need to send the C0 command before the SendToClient command. The WhosOn Server assumes the user has stopped typing when it receives a SendToClient command.
When another client user sends you a message you will receive the fromclient event:
Header contains the Connection ID of the sending client and Data contains the message text.
When another user that you are chatting to starts typing you will receive:
Data contains the Connection ID of the client user you are chatting to.
When the other user stops typing you will receive:
The WhosOn Server stores user-to-user chats in the database. This can be enabled/disabled for each user.
If your connected user has 'User-To-User Chats Are Stored In Database' user right, you can read previous chat lines for any user-to-user chat using the GetClientChat command:
Parameters:
The WhosOn Server will send the clientchat event. The other user will also need the 'User-To-User Chats Are Stored In Database' user right.
The lowest id parameter is used for paging. For each GetClientChat command the server will send a maximum of 100 lines. If the lowest id parameter is zero, then the most recent 100 lines will be sent. Each line sent contains an ID. To retrieve more lines, send the GetClientChat command again but with the lowest ID that you last received.
You can use the GetClientChat command for any user that your connected user has access to - the other user does not need to be logged in at the time.
Header will contain the other username.
Data will contain a list of chat lines. Lines are returned in reverse order - starting with the newest.
The Dated property is the date/time of the line in UTC.
The MyLine property will be True if the line was sent by your connected user to the other user and False for the other way around.
If the 'Search Text' parameter of the GetClientChat command was specified, then only lines containing the search text will be returned.
If your connected user has 'Admin' user right you can send a message to all connected users (that the logged in user has access to), using the BroadCast command:
Parameters: Message to send.
All users that the logged in user has access to will receive a msg event.
To change the current status of the connected user, send the Status command:
The first parameter is the status number: 0=Online, 1=Busy, 2=Be right back, 3=Away
The second parameter the optional and can be set to a string status message.
Whenever any user status changes (either manually or by the server) all connected users that have access to the user will receive a clientevent.
The clientevent will also be received when another user takes or closes a chat (IE: the Chats property changes).
If your connected user's status is changed by the WhosOn Server (for example: by the users Work Period start or end time being reached), or by another user, your client will receive a status event.
Data will contain your new Status number (0=Online, 1=Busy, 2=Be Right Back, 4=Away).
If your connected user has 'Team Leader', 'Supervisor' or 'Administrator' user rights, you can change the current status of another connected user (that the logged in user has access to). Send the SetStatus command:
Parameters: Connection ID of the user you want to change, Status number:
The other user will receive a status event.
All users will receive a clientevent indicating that the user's status has changed.
Team Leaders can only change the status of users in their own user group.
Whenever any user logs out all other users that have access to that user will receive a clientremove event.
Data contains the Connection ID of the user logging out.
You would use the clients, clientevent & clientremoved events to maintain a list of other connected users that you can display in your client and to do user-to-userchat.
When the user logs out you should send a Close command:
You should then disconnect the WebSocket connection.
You can just disconnect the WebSocket connection without sending close beforehand and the WhosOn Server will handle it - however it is recommended to send close first.
The WhosOn Server may close your connection for some reason (server shutting down or the user's properties have changed requiring a re-login). In these cases, the server will send a close event. And then disconnect the WebSocket.
After you have logged in your client will receive the chatting event containing a list of all current chatting visitors. After this, individual chatchanged and chatclosed events will be received for each chatting visitor.
All chatting visitors are sent to your client - for all sites that the logged in user has access to. Including chatting visitors that are chatting to other users.
The chatchanged event will be sent for any new chat and when an existing chat changes (eg: It is picked up by a user).
The WantsSkills of the chatting and chatchanged events contains a comma-separated list of Skill ID's assigned to the chat. The WhosOn Server assigns skills to each chat based on the chat routing rules defined for the site. If the WantsSkills for a chat is blank then the chat has no specific skills and can be taken by anyone.
Once a chat is picked up by a user the TalkingToClientNo property will contain the Connection ID of the user that has taken the chat:
The MonitoredBy property will contain the users name if it is being monitored.
When a chatting visitor is removed the chatclosed event will be sent. Data contains the ChatUID.
You would use the chatting, chatchanged & chatclosed events to maintain a list of current chatting visitors to display in your client.
You should update a list of chatting visitors in your client. Chats with TalkingToClientNo = 0 should be displayed separately - showing that these are waiting to be picked up.
When a visitor requests a chat a chat event is sent to all connected users who can take the chat.
The WhosOn Server will handle chat routing and only send the chat event to users who are able to take the chat based on current status, skill assignments, chat routing rules, chat queuing, maximum chat settings, user rights, opening hours etc. Therefore, if your client user receives a chat event it should display a notification and offer the user the option to take it - since the WhosOn Server has already decided your user is able to do so.
Header will be null.
Data contains colon separated fields:
You can use this event to show a new chat notification message.
A chatchanged event will also be sent (to your client and all others).
To take the chat send a Chat command:
The first parameter is the Chat Number.
If the WhosOn Server accepts the chat take request it will send a chataccepted event:
Header will be null.
Data contains a colon separated fields:
A chatchanged event will also be sent (to your client and all others).
If the WhosOn Server does not accept the chat take request it will send a msg event:
The WhosOn Server may require your client to auto accept a chat instead of giving the user the option. In these cases, the acceptchat event is sent:
The parameters are the same as the chat event. Your client should accept the chat by sending the Chat command as above without giving the user the option.
After the chataccepted event has been sent the WhosOn Server will send the prechatsurvey event.
Header will be a colon separated list of fields:
Data will contain a list of pre-chat survey fields completed by the visitor.
If the picked-up chat already has chat lines (for example: it was picked up by another user and has been transferred, or the visitor has sent some chat lines before the chat has been picked up), then a currentchat event will be sent. This contains all survey data & previous chat lines.
Header will be a colon separated list of fields:
The TakenByUser property contains a comma separated list of operator names that have chatted to the visitor (there could be more than one if the chat has been transferred). The OperatorIndex property of each chat line contains the index to this list (1 based). For example if TakenByUser is set to 'Thomas,Daniel' and the OperatorIndex for a line = 2 then the line was sent by 'Daniel'.
OperatorIndex = 99 refers to lines created server-side.
If OperatorIndex = 0 then the line was sent by the visitor.
The VisitDetail property will contain the VisitDetail object (see the GetVisit command).
When another user transfers a chat, the WhosOn Server will send a transfer event to all users selected for the transfer.
Header will be null. Data will be a colon separated list:
Note: Since 'message' could contain colons you should split the first 2 fields and assume the remaining is the message. This message can be used to show a popup, or you can create your own.
To accept the transfer, send the Chat command as with regular chats.
The WhosOn Server will send a chatclosed event whenever any chat is closed (including your users own chats). Chats can be closed either by the visitor or user. Data will contain the ChatUID.
Once a chat has been accepted you can send and receive messages and perform other operations.
To send a message send the SendTo command:
Parameters: Chat Number, Message Text.
The WhosOn Server will then forward the message to the visitor's chat session. The message text can be up to 4000 characters.
If Translation is enabled for the Site (as indicated by the TranslationEnabled property in the Sites event) and the visitor has requested translation for their chat session (as indicated by the Translation property of the chatting visitor in the Chatting and ChatChanged events) then the WhosOn server will automatically translate messages sent by client users to visitors before forwarding the message and the translation to the visitor's chat session.
If the WhosOn server has translated the message text in the SendTo command it will send a SendToTranslated event back to the client:
Header will contain the chat number.
You can use this event to update your chat view if you wish to show the translated text.
If you prefer to handle translation in your client using your own or 3rd party translation service, rather than the
WhosOn server performing the translation, add <Translated> translated text </Translated> to
the end of the message. The Lang property of the chatting visitor will be set to their 2 character language
code.
If the message sent with the SendTo command already contains a <Translated> tag
the server will skip translation and the SendToTranslated event will not be sent. If you are
providing your own translation then the <Translated> tag can be added to messages regardless of
if Translation is enabled on the Site.
Messages sent to visitors using the SendTo command can contain 'Markdown'. Markdown is a lightweight markup language with plain text formatting syntax. See: Markdown Guide
If messages are sent containing Markdown the WhosOn Server will automatically convert the message to equivalent HTML before forwarding it to the chat session.
For example:
Note: \n newline marks have been removed from the above message for readability.
To send a file send the SendFileTo command:
Parameters: Chat Number, File Name, URL.
The URL should be the URL to one of the files in the uploaded files list sent with the UploadedFiles event.
During a chat you can send your client typing status. This will show in the visitor's chat window as an 'Operator is typing' indicator.
To enable typing indicator, send the StartTyping command:
Parameters: Chat Number.
To disable the typing indicator, send the StopTyping command:
Parameters: Chat Number
In your client application you need to enable a timer when the user presses a key in the chat message text box. If the timer was not already enabled – send the StartTyping command and enable the timer. If the timer is already enabled – record the time of the last keypress. In the timer event compare the last key press time with the current time and if a period of (say) 2 seconds has elapsed – send the StopTyping command and disable the timer.
Note: You do not need to send the StopTyping command before the SendTo command. The WhosOn Server assumes the user has stopped typing when it receives a SendTo command.
To request a file from the visitor, send the FileRequest command:
Parameters: Chat Number.
Dynamic Fields are pre-defined input requests with their own prompt, field type & validation rules. A list of available Dynamic Fields is sent in the Sites event. To request the visitor to complete a dynamic survey field send the FieldRequest command:
Parameters: Chat Number, Dynamic Field Name, Prompt Text.
The Dynamic Field Name must be one of the defined Dynamic Fieldname names.
If the prompt text is blank, then the default prompt of the selected field will be used.
The visitor must then complete the field input in the correct format in their chat session. The result of the completed field will be sent as a regular Message event.
To request that another supervisor user monitor your chat session send the RequestMonitor command:
Parameters: Chat Number, Request Message.
The message text is optional.
A RequestMonitor event will then be sent to all other users who are able to monitor the chat.
To block a visitor's IP address and prevent chats from that IP from starting another chat for the next 24 hours send the Block command:
Parameters: IP address to block. You cannot block IP's that are in the whitelist.
If the CRM settings allow client update, you can flag a chat to be sent to the CRM when the chat ends by sending the CRMPost command:
Parameters: SiteKey, ChatUID, optional 'disable'.
If the last parameter is equal to 'disable' then the CRM update will be switched off if it was previously enabled.
You can request that the WhosOn Server send an email transcript of the chat. This can be done at any time - during a current chat or for a previous chat. Send the SendTranscript command.
Parameters:
Chats can be transferred to other users, departments or skills.
To transfer a chat to another user, send the Transfer command:
Parameters: Chat Number, Comma Separated list of client Connection IDs to send the transfer request to. Optional message. The WhosOn Server will send the transfer event to the client users specified.
You should check the Status of each of the other clients - and only include clients that are available (Status=0).
To transfer the chat to another department, send the TransferDept command:
Parameters: Chat Number, Department name, optional message. The WhosOn Server will send the transfer event to only those client users that have a matching department.
To transfer the chat to another skill, send the TransferSkill command:
Parameters: Chat Number, Comma Separated list of Skill Id's, optional message. The WhosOn Server will send the transfer event to only those client users that have all the skills specified.
Client users that receive the transfer request will receive a transfer event:
Data contains the Chat Number and the client Connection ID of the client user making the transfer request.
Clients that receive this event should display a message saying that "User {name} would like to transfer a chat with {visitorname}".
The client user that wishes to take the transfer should then send a Chat command to join the chat session.
After sending any of the Transfer commands your client user should leave the chat, allowing other users to pick it up. Send the Leave command.
After accepting a chat, you can request additional visitor detail from the WhosOn Server by sending the GetChatVisit command. This can be displayed in a 'Visit Detail' section of the chat session view. This is optional.
Parameters: SiteKey, Visitor IP Address, Visitor Session Id, ChatUID.
The WhosOn Server will respond with a visitdetailchat event.
Header will contain SiteKey:IPAddress:VisitorSessionID:ChatUID
Data will contain the visit detail.
The WhosOn Server will send a message event whenever a chat message from a visitor is received.
Header will contain the chat number. Data will contain the message text.
Note: The message event will be sent for your own current chats and for chats that have not yet been picked up. For example: A visitor starts a chat and sends some chat lines before anyone has picked up the chat. If the Chat for the Chat Number TalkingToConnection property is zero, then you should display a notification with the message text - indicating a visitor has said something but no user has yet picked up.
If the message contains a translation the <Translation> text </Translation>
will be appended to the message text. You should extract the translated text from the message and display this in
the chat session view (along with the untranslated text).
The WhosOn Server will attempt to match the visitor message to a Canned Response and/or a recent previously sent
message. If a match is found, then a <Suggest> tag will be appended to the message text. Eg:
You can use this to optionally show the suggestion to the user or pre-fill the user chat text with the suggestion.
If the suggestion contains an attachment, then the <Suggest> tag will include it:
Note: You need to remove the <Suggest> tag from the message text before showing the message in
the chat view.
The WhosOn Server searches Canned Responses first. If no matching Canned Response is found it searches previous chats for responses to similar visitor messages (for recent user chats with matching skills).
The WhosOn Server may send messages to the visitor for chat inactivity messages or if a visitor message has been filtered due to Chat Text Rules. These messages are also forwarded to the client.
You can show these messages in your current chat view or ignore them.
When a visitor starts or stops typing the WhosOn Server will send 1 and 0 events:
Data will contain the Chat Number. You would use this to show a 'Visitor is typing' indicator in the selected chat session. Your client will only receive these events for currently active chats.
Note: A StopTyping event will not be sent prior to a Message event. You should assume that when a visitor sends a message that they have stopped typing (for the current message).
If typing preview is enabled for the site, then the WhosOn Server will send the preview event periodically whilst the visitor is typing. This enables the user to see what the visitor has typed before the visitor sends the text:
Header will contain the chat number.
Data will be the text typed so far by the visitor.
When a visitor uploads a file during a chat the WhosOn Server will send the fileupload event:
Header will contain the chat number.
Data will the file name and URL separated by a TAB character.
The URL will be the URL to the document.aspx page pointer in the WhosOn web services.
The fileupload event will be sent only to your client's active chats. However, all other clients (including yours) will also receive a fileuploaded event:
All client users that have access to an uploaded file will receive a fileuploaded event when a visitor uploads a file (that is not marked as single use).
This is so that other clients can update their lists of uploaded files.
If a visitor supplies an email address during a chat or as part of a pre-chat survey you can request that the visitor validates it using the SendTwoFactorAuth command.
Parameters:
The WhosOn Server will then send an email to the email address given. The visitor can then enter the code into their chat session - indicating to the user that their email address is valid and that they have access to it.
If the Message parameter is blank it will default to: 'Please enter the code below into your chat session to verify:'.
The Validation code parameter should be a random code.
Once the SendTwoFactorAuth command has been sent you should wait for the Validation code to be sent back in the message events. Receiving the code back indicates that the visitor has received the email and therefore the email address must be valid.
To close a chat, send the CloseChat command:
Parameters: Chat Number
This command should be used where the user closes the chat. The Visitor can also close a chat - in which case the chatclosed event will be sent. Your client will also receive the chatclosed event for user closed chats.
Parameters: Chat Number
This command should be used when the user closes an asynchronous chat, but wants to leave open the possibility for the resumption of the chat at a later date. This marks the chat as "Soft Closed".
Parameters: Chat Uid, Sitekey and Y/N for assign to me.
If assign to me is Y then the server will assign it to you. If it is N then the chat will go into the waiting chat list for the next available operator.
Your client user can leave a chat instead of closing it. Leaving a chat keeps the chat session open on the WhosOn Server - for other users to pickup.
Parameters: Chat Number
You should send the Leave command after any Transfer commands.
To add wrap up information for a chat send the ChatWrapUpComplete command.
Parameters: SiteKey, ChatUID, Value
The chatwrapupcomplete can be sent at any time during a chat or after it has been closed.
Chats can be assigned any number of tag values. Tags available for a site are returned with the Site data in the sites events. These can be overridden with any arbitrary value.
To assign tags to a chat send the ChatAddTags command.
Parameters: SiteKey, ChatUID, Tags (single string with tags separated by TAB).
The chataddtags can be sent at any time during a chat or after it has been closed. Any existing tags assigned to a chat will be replaced.
Chat tags allow chats to be reported on by tag value and 'Tag Cloud' style reports to be created. Tags will show in the modern client in the Previous Chat view.
When a visitor completes a post-chat survey the WhosOn Server will send a postchatsurvey event to all connected users who have access to the chat.
Header will be a colon separated list of fields:
Data will contain a list of post-chat survey fields completed by the visitor.
You can use this to update a list of closed chats if you are showing these or ignore the event. Your client would have already received a chatclosed event.
You can assign contact information to any visitor. This can be done during a chat or against any previous chat or visitor. These fields are in addition to any pre-chat survey fields. Contact information stays with a visitor across multiple visits and shows in the VisitDetail and VisitList.
To add/update contact information send the Contact command:
Parameters: SiteKey, IPAddress, Visitor Session Id, Contact fields.
All fields should be sent. If a field is a blank string, then the existing value will not be overwritten. So, to just update an email address you would send:
Once contact information is assigned to a visitor it will show in the Visit Detail for against subsequent visits for the same SiteKey, IPAddress, Visitor Session ID.
Note: Contact information is automatically added to visitors by the WhosOn Server for name, email, company & phone when a visitor starts a chat and provides any of these fields in the pre or post chat survey.
When the contact update has been accepted by the WhosOn Server it will send an accepted event:
The accepted event will also be sent in response to Invite, Block & ClearBlacklist commands.
If your connected user has 'Can Monitor Other Users Chats' user right then they can monitor other users active chats and can receive requestmonitor events from other users.
To start monitoring a chat send the Monitor command:
Parameters: Chat Number
You can only monitor chats that are not already being monitored and have been taken by another user (the TalkingToClientID is not zero).
If the WhosOn Server accepts the monitor request it will send the monitoring event:
Header will be null. Data will contain the Chat Number and the Client Connection ID separated by a colon. The Client Connection ID is the ID of the client user that is currently chatting to the visitor.
After this event the WhosOn Server will send a monitoredchat event.
This event contains the same data as the currentchat event. It contains visitor information, survey fields and all chat lines so far.
The VisitDetail property will contain the VisitDetail object. See: GetVisit
When the client user that is chatting to the visitor sends a message the WhosOn Server will send a monitorc event to the client user that is monitoring the chat.
Header will contain the Chat Number and the other client name separated by a colon.
Data will contain the message text.
When the visitor sends a message to the client user that is chatting to the visitor the WhosOn Server will send a monitorv event to the client user that is monitoring the chat.
Header will contain the Chat Number and the other client name separated by a colon.
Data will contain the message text.
When either the chatting user or chatting visitor typing status changes for a monitored chat the WhosOn Server will send m1,m0,mc1 or mc0 events.
Data will contain the Chat Number and the chatting users name separated by a colon.
Data will contain the Chat Number
Whilst monitoring another chat your client user can send private messages that only show to the other user (not the visitor). You can send a whisper message to a monitored chat by sending the Whisper command:
Parameters: Client Connection ID (of other user), Chat Number, Message text.
The other client will receive a whisper event:
Header will contain the Chat Number and sending client name separated by a colon.
Data will contain the message text.
If another user that is chatting to a visitor has requested someone to monitor the chat, the WhosOn Server will send the requestmonitor event. This event will only be sent to users who can monitor the chat (based on their user rights).
Header will contain a TAB separated list of fields:
You would display a message to the user asking the user to monitor the chat.
To stop monitoring a chat send the StopMonitor command.
Parameters: Chat Number
The WhosOn Server may also send a monitorstop event if you are monitoring a chat and the chat ends before you have sent the StopMonitor command.
Header will be null, and Data will contain the Chat Number and the chatting users name separated by a colon.
Chats that you are currently monitoring can be Acquired (taken from the user currently chatting and transferred to your user).
To Acquire a chat, send the AquireChat command:
Parameters: Chat Number
A chataquired event will be sent to the client user that is currently in the chat session:
Data will contain the Chat Number and the user's name that is acquiring the chat separated by a colon. The Client receiving this event should display a message saying the 'Chat has been acquired by {name}' and exit the chat (without closing it using the Leave command).
A monitorstop event will be sent to your client.
A transferconfirmed event will be sent to your client:
Data will contain the Chat Number. You should then send a Chat command to open the chat session.
Clients can request information for previous chats that the current user they are chatting with has had.
To request a list of previous chats for this session, send the GetPrevChats command
When using a channel based chat session, use the GetPrevChatsChannel command
Parameters: Sitekey, IP Address, Optional Department
The server responds with the PrevChats event.
Parameters: Sitekey, Channel Name, Channel User ID, Optional Department
The server responds with the PreChatsForChannel event.
Header will contain the SiteKey and IP address separated by a colon.
You can then request the detail for any chat by sending the GetPrevChat command.
Header will contain the SiteKey, channel name and channel user id separated by a colon.
You can then request the detail for any chat by sending the GetPrevChat command.
Clients can request list of previous chats for any site/day and request chat searches.
To request a list of previous chats for a site send the GetChats command:
Parameters: SiteKey, Date.
The WhosOn Server will respond with a chats event.
Header will contain the SiteKey and date separated by a colon.
Data will contain a list of chats for the selected date.
You can then request the detail for any chat by sending the GetPrevChat command.
Parameters: SiteKey, ChatUID.
The WhosOn Server will respond with a prevchat event:
If the connected user has the 'Can Delete Chats' user right, then previous chats can be deleted. To delete chats, send the DeleteChats command:
Parameters: SiteKey, Comma separated list of ChatUID's to delete.
When chats are deleted the WhosOn Server will send a deletedchats event to all connected users who have access to the deleted chats.
To perform a search, send the command GetChatSearch:
Parameters: SiteKey, From Date, To Date, Search Text.
Chats will be returned that contain the search text (not case sensitive). All chat lines are searched in addition to header information (visitor name, pre/post chat survey values, visitor location, email address, left message text).
The WhosOn Server will send a chatsearch event with the results of the search.
Header will contain the SiteKey, From Date and To Date separated by colons.
Data of this event is the same as the chats event.
After login your client will receive a missedchats event containing a list of pending missed chats that the connected user has access to. After login, individual missedchat events will be sent whenever a new missed chat is added. Missed chats can be responded to by the user. When a missed chat is responded to, the WhosOn Server will send the response to the visitor via email or if the visitor has provided a telephone number the missed chat can be responded to via a CallBack (if Callbacks are enabled for the Site).
To start a response, send the MissedChatResponding command. This command informs the WhosOn Server that a user has started a response to a missed chat. This prevents other users from also starting a response to the same chat at the same time. Only users who have the 'Can Respond To Missed Chats' are be allowed to do this.
Parameters: ChatUID
If another user has already started responding to this missed chat a msg event will be sent:
Send this command to send a response to a missed chat. The WhosOn Server will append the message text to the chat and send an email to the visitor with the response. The missed chat will be marked as completed and removed from the missed chats list. All users who can see the missed chat will receive a missedchatclosed event.
Note: The message text can contain Markdown.
Data will contain the Chat UID.
The WhosOn Server will send the missedchatclosed event whenever a missed chat has been responded to (by any user) or has expired (missed chats can be set to expire after a number of days defined on the Site Properties).
If the client has started a missed chat response by sending the MissedChatResponding command and wishes to cancel the response, send the MissedChatPespondingCancel command with the single parameter of ChatUID.
The client can initiate a Twilio callback for any chat (current, previous or missed).
To start a callback send the CallBackStart command:
Parameters: SiteKey, ChatUID, Phone Number.
The WhosOn Server will start the callback process.
During the call back the WhosOn Server will send progress events in the chatcallbackevent
This event will be sent multiple times during a call as the call status changes. You should display the TranscriptLine property in your chat view.
A list of Canned Responses can be requested by sending the GetCannedResponses command.
Canned Responses can also be added, updated & deleted by the client.
Send the CannedResponseUpdate command to add or update a canned response:
Where XML is in the following format:
For new responses the <CannedID> should be zero. To update an existing response set its
<CannedID> to an existing ID.
If the Canned Response should be added as a child of an existing response set the
<ParentCannedID> to the parent id.
If the Canned Response is a 'My Canned Response' - IE only available to the user who created it, set the
<SkillID> to -1
<Sitekeys> should be a comma separated list of sitekeys that this canned response is available
for. If blank then the sitekeys of the user adding it will be used.
Whenever a canned response is added or updated the WhosOn Server will send a cannedresponseupdated event to all users who have access to it (including your client).
Data will be the XML of the canned response. For new responses the <CannedID> will contain the
new id. If Data does not contain XML it will contain an error message indicating why the canned response could not
be updated.
To delete an existing response, send the CannedResponseDelete command:
Parameters: The Canned ID to delete.
Whenever a canned response is deleted the WhosOn Server will send a cannedresponsedeleted event to all users who have access to it (including your client).
Data will contain the Canned ID deleted. If not a number, then it will contain an error message indicating why the Canned Response could not be deleted.
Note: When deleting canned responses - if the canned response has child responses then all child responses will be deleted also - however your client will not receive events for all the children - only the parent.
You client should get the initial list of Canned Responses and then monitor the CannedResponseUpdated and CannedResponseDeleted events to maintain the list when other users are changing them.
A list of Files can be requested by sending the GetFiles command.
To add a new file, you must call the DocumentWrite web service. The web services URL is passed as part of the connected event. This web service returns a URL, or 'Error [message]'' if an error occurred. If a URL is returned you can then use this with the SendFileTo command if you have uploaded the file during a chat session and then want to send it to the visitor.
Files can be deleted by the client by sending the DeleteFiles command:
Parameters should contain a comma separated list of hashed filenames to delete.
A deletedfiles event will be sent to all clients that have access to the file(s) deleted. Clients can then remove the files from their files list.
Data will contain a list of hashed file names deleted separated by a comma.
Existing files can be marked as 'Pinned' by sending the PinFiles command:
Parameters should contain a comma separated list of hashed filenames to pin. If files are already pinned, they will be marked as unpinned.
The initial clients event that the WhosOn Server sends after login provides a list of other connected users.
The clientevent and clientremove events provide updates as users login, change status etc and logout.
Your client can also request avatars for any user by sending the GetUserPhotos command:
Parameters: Tab separated list of usernames to request photos for.
The WhosOn Server will send a userphoto event for each user requested:
Header will contain the username. Data will contain a base64 encoded string of the user image (or blank if no image).
Note: User images should be cached in some way by the client rather than requesting after each clients or clientevent events.
Your client can request traffic summary data for the current day and as a single request for the last 3 months.
To request traffic summary for the last 3 months, send the GetMonthSummary command:
Parameters: SiteKey
The WhosOn Server will send a monthlysummary event containing:
Each Day in the Days list contains the Date and Data properties.
The Data property is a Pipe (|) delimited string of:
The monthly summary will not include the current day. For the current day use the GetDS command.
Monthly summary dates will be in date order and it is possible for there to be gaps in days (for instance if the server was not running on a particular day). When implementing a 'back', 'forward' view of dates in a client summary view you should maintain the current date in the view and then search for it in the list (and display zeros if no date found) - rather than going back/forward in the list itself.
The GetDS command is used to get the current traffic summary for all sites (that the logged in user has access to).
The WhosOn Server will send the ds event:
The DaySummary list will contain current totals for each site.
Your client can request an update of the current traffic summary at any time but should limit the requests to as needed (IE when the user clicks a 'summary' view - if the last update was less than 2 minutes ago).
You can request to just get current visitor totals only. This provides a smaller event and is better for performance if you want to show current visitors for each site in your client.
Send the GetCT command:
The WhosOn Server will respond with the ct event:
The Current list will contain an entry for each site that the logged in user has access to. The Visitors property contains the current active visitors for the site. You can enable Current Visitor Totals events so that the ct events are sent automatically.
You can request that the server sends the ct event automatically whenever the visitor current totals change.
Send the StartCurrentVisitorTotalsEvents command:
Once enabled the server will automatically send a ct event when current visitor totals change. Events are sent approximately every 8 seconds (unless there has been no change, in which case an event is not sent).
To disable Current Visitor Totals events, send the StopCurrentVisitorTotalsEvents command:
Listen mode can be enabled by users with Admin, Supervisor or Team Leader rights (and have the 'Can Monitor Other Users Chats' user right). Once enabled all active chat messages are sent to the listening client as they occur. This enables the creation of a 'supervisor view' to monitor the activity of all active chats for all users (that the logged in user has access to). Team Leaders can only see chats that are interacting with users in their own user groups.
To enable Listen Mode, send the StartListening command:
To disable Listen Mode, send the StopListening command:
These commands will be ignored by the WhosOn Server if the user does not have sufficient rights.
Once Listen Mode is enabled then your client will receive events for all chat sessions, for all users (the the logged in user has access to).
When the client user that is chatting to a visitor sends a message the WhosOn Server will send a listenc event to all client users that have Listen Mode enabled.
Header will contain the Chat Number and the Chat UID separated by a colon.
Data will contain the message text.
When the visitor sends a message to a client user the WhosOn Server will send a listenv event to all client users that have Listen Mode enabled.
Header will contain the Chat Number and the Chat UID separated by a colon.
Data will contain the message text.
If a chat is transferred the WhosOn Server will send a listentransfer event to all client users that have Listen Mode enabled.
Header will contain the Chat Number, Chat UID and Transfer target (Name, Department or Skill) separated by colons.
When creating a supervisor view to monitor all chats you should follow these tips:
The WhosOn Server tracks all visitor activity for each monitored Site. By default, the WebSocket interface does not send individual visitor events unless visitor events are enabled.
The current visitors list can be requested by sending the GetVisitors command:
The WhosOn Server will respond with the visitors event:
Data contains a list of active visitors for all monitored sites (that the client user has access to).
The GetVisitors command should be sent once after login if you want to monitor active visitors in your client.
Visitor events can be enabled by sending the StartVisitorEvents command:
And disabled with StopVisitorEvents command.
Once Visitor Events are enabled the WhosOn Server will send a visitor event whenever a new visitor arrives at a site and when a visitor changes (for example, requests a new page or their IP address is resolved to a DNS name, or the visitor becomes a prospect etc). It will send a visitorremoved event whenever a visitor leaves a site.
The Key property contains a string combining SiteKey:IPAddress:VisitorSessionID. This can be used as a unique key for the visitor. The No property is the visit number for the site for the current day. The VisitNo is the visit number for that visitor (IE: If it is the 2nd visit to the site for the same Key then VisitNo would be 2).
The Flags property is a string containing Y and N characters which indicate (Y or N by position):
The WhosOn Server will send this event when a visitor leaves the site. Data contains SiteKey: IP Address: Visitor Session ID (the Key property of the visitor event).
You can request the visit detail for any active visitor. Use the GetVisit command:
Parameters: SiteKey, IP Address, Session ID, VisitNumber
The WhosOn Server will send a visitdetail event:
The VisitDetail event contains the visit detail object which contains information about a specific site visitor. The Pages list contains a list of page views for the visit. The FormFields list contains a list of completed form fields (if form-field tracking is enabled). The GeoIP property contains the GeoIP information for the visitor's IP address.
The WhosOn Server will enable 'Visitor Throttling' when the currently active visitors for a site reaches 20% of the maximum allowed active tracked visitors setting (which defaults to 1000, so by default throttling will start at 200 active visitors or more). Visitor throttling is designed to improve the performance of operator client applications to prevent them from being overwhelmed by single visitor & visitorremoved events.
When the WhosOn Server enables visitor throttling, single visitor events and visitorremoved events will not be sent. Instead, visitor events will be sent as a batch every 8 seconds. The visitorbatch event will be sent which will contain a list of visitors added or changed since the last batch. The visitorremovedbatch event will contain a list of visitor keys to remove.
See the WhosOn 2019 Server release notes for more information about visitor throttling.
The WhosOn Server will disable Visitor Throttling when the currently active visitors for the site drops to below 75% of the throttle level. Regular visitor and visitorremoved events will then resume.
The WhosOn Server will automatically send chat invites based on Invite & Prospect Detection rules. In addition, client users can manually send invites to any active visitor. If your connected user has 'Can Send Chat Invites' user right, you can send a chat invite request to any active visitor. The invite will appear on the visitor's web page according to the design specifications of the invite type being sent. Send the Invite command:
Parameters: IP Address, Visitor Session ID, Domain Name, Invite Number.
Note: The site domain name is passed here, not the sitekey.
The WhosOn Server will respond with an accepted event:
If you want to offer a live visitor view in your client, you should first send the GetVisitors command after login. Followed by the StartVisitorEvents command. Then maintain a list of active visitors for each site by handling the visitor,visitorremoved, visitorbatch & visitorremovedbatch events to update & delete from the list.
For very busy sites with many active visitors (>500) performance becomes a consideration. You can examine the current property in ds event to see the total current visitors for a site. The Visitor events can be disabled if the current visitors count gets too high.
Visitor events should not be enabled if the client user does not need to view active visitors and instead wants to focus on chatting visitors only.
Visit lists for the current day or any previous day can be requested using the GetVisitList command:
Parameters: SiteKey, Date, From ID
The WhosOn Server will respond with a visitlist event:
The list will contain every visit for the requested Site & Date.
The FromID parameter of the GetVisitList command is used when requesting the visit list for the current day. If requesting visit lists for previous days send "0".
The FromID parameter allows you to request only new visits since the last request. The VisitID property on each Visit contains the ID. Store the highest ID from the last request and then send that on subsequent requests to receive new visits.
For each visit record:
The remaining fields are related to that visit.
The Flags property is a string containing Y and N characters which indicate (Y or N by position):
You can use the GetVisit command to request visit detail for any visit.
You should cache visit lists for previous days rather than re-requesting the list from the WhosOn Server.
When viewing for the current day use the 'FromID' parameter to only request new visits since the last request.
These commands are stand alone and can be sent at any time (once logged in).
The WhosOn Server automatically scores chats for sentiment and automatically trains the Sentiment database based on the Rating field of completed chat Post-Chat Surveys. However, you can use these commands to score & train the Sentiment Analysis database independently. You must be logged in with a user with Admin user rights to use these commands.
This command can be used to score any text for sentiment.
Parameters: SiteKey, Text to be scored.
The WhosOn Server maintains separate sentiment training data for each site. You must pass the SiteKey to use for the scoring. The logged in user must have access to the site.
The server will respond with a sentimentscore event:
Data will contain the score. 100 being maximum positive, 1 being maximum negative. 50 is neutral. Zero indicates the text could not be scored.
This command is used to add POSITIVE training data to the sentiment database.
Parameters: SiteKey, Text to be trained.
The WhosOn Server maintains separate sentiment training data for each site. You must pass the SiteKey for the site you wish to train.
The server will respond with a sentimenttrained event:
Data will contain the updated score for the trained text. The training will affect any new sentiment scoring for chats against the site specified.
This command is used to add NEGATIVE training data to the sentiment database.
As with the SentimentTrainPos command, however the text will be trained as negative sentiment.
The SentimentTrainPos & SentimentTrainNeg commands can be used to train the Sentiment Analysis for any given site. This will improve accuracy of chat scoring.
This command can be used to summarize any given text. The WhosOn Server automatically adds summary text to each chat, however you can use this command to summarize any text independently.
A summarizedtext event will be sent.
Parameter: The text to be summarized.
Data will contain a summary of the text sent with the last SummarizeText command. The Summarizer algorithm attempts to extract the most important part of the text. If the text cannot be summarized, then a blank string will be returned.
The GetGeoIP command can be used to retrieve Geo-IP data for any IP address. The WhosOn Server automatically assigns Geo-IP data to all visitors and chat sessions, however you can use this command to lookup Geo-IP for any given IP address.
Parameters: IP address
A geoip event will be sent:
Note: The GeoIP data provided by WhosOn should only be used to provide location data for WhosOn users. It is beyond the WhosOn license scope to use the geo-ip data to pass on to 3rd parties or use in applications outside the scope of WhosOn.