Events

Not all events can have webhooks registered, this is to avoid having useless triggers configured. The following list contains all events for which you can register webhooks:

agents:login

Any time an agent logs into the live chat platform, i.e. starts his/her session.

agents:logout

Any time an agent logs out of the live chat platform, i.e. finishes his/her session.

chats:create

Any time a new chat is created.

chats:join

Any time a user joins a chat.

chats:leave

Any time a user leaves from a chat. 

chats:close

Any time a chat is closed.

chats:assign

Any time a chat is looking for an agent to attend it. It’s fired each time an invitation “jumps” to one agent to another. If a valid agent ID is returned in this webhook, the chat is assigned to this agent. 

chats:toinbox

Any time a chat is sent to another room’s “inbox” (or to the same one’s).

forever:alone

Any time that, for the current chat, there are no more agents available to be invited. Given this event, one could restart again the assignation loop or just close the chat. 

invitations:new

Any time an invitation to join a chat is sent to a user.

invitations:accept

Any time a user accepts an invitation for a chat.

invitations:reject

Any time a user rejects an invitation for a chat.

messages:new

Any time a message is sent to an open chat. 

rooms:join

Any time a user joins one or several rooms. 

rooms:leave

Any time a user leaves from one or several rooms.

users:signup

Any time a new user is registered.

Payloads

The Live Chat server will send POST messages to the target URL(s) when a configured event happens. This messages have the following payload structure (with application/json encoding):

{
  trigger: {{event_name}},
  appId: {{app_id}},
  data: {{object}}, // each event has different data
  created_at: {{unix_timestamp}}, // the time on which the webhook was fired
}

Inside the “data” property there is the information of the kind of event that has been received. Each event type has a specific format with the relevant event information. All event data payloads mirror the responses of the API routes.

Note that this events’ data is “skinny”. You should make additional calls to the API to retrieve the latest state if your integration needs more information.