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:

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. The timeout to return a successful response is 5 seconds and it cannot be modified.

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:accept

Any time a user accepts an invitation for a chat.

messages:new

Any time a message is sent to an ongoing chat conversation.

messages:read

Any time a message is received in an ongoing chat conversation. 

queues:update

Any time a chat moves to a new position within its queue.

system:info

Any time a new system event occurs (for example, when a ticket is created upon the closing of a chat).

users:activity

Any time a user performs an action, such as:

• Start writing
• Stop writing
• Leave the chat (meaning the period in which the user is not connected and the system waits a reasonable amount of time for the possibility to reconnect)

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.