Rocket.chat: Livechat external API

[sampaiodiego]

As mentioned at https://github.com/RocketChat/Rocket.Chat/issues/1824#issuecomment-170031567 there is a need for some interaction from the website who offers the livechat and livechat app itself.

Possible functions that this API coud have:

• visitor:
  
  
  
  • get information about visitor: name, email, IP, etc
  
  
• window:
  
  
  
  • open/close window
  
  
  • set size
  
  
  • set position
  
  
  • open the pop-up
  
  
• events (with callbacks):
  
  
  
  • start/stop chatting
  
  
  • possibility to override some information (like agent, department, etc) inside the start callback
  
  
  • open/close window
  
  
  • send pre-register form
  
  
• ...

[sampaiodiego]

FYI @cmcardle75

[cmcardle75]

Some ideas for API calls, in order of decreasing importance. This is quite a wish list, but it would be demo-able with only the first few items on each list. Also, some of these requirements might already be available using existing packages and others might be got for free designing some of the earlier ones to allow them.

Note that the routing to an agent must be asynchronous, as it could be some time before an agent is available. This could be done by putting the visitor in their own private room, but not assigning an agent to that room until the routing request is received. There wouldn't be any need to tell the visitor what is happening. We would be able to do this ourselves with programmatic sending of messages. We probably don't need the department concept.

API (calling into LiveChat from external service)

• Add agent to chat
• Remove agent from chat
• End chat (might just be last agent removal, but preferably not, as we might want to put the chat back into the queue (or a more specialised one) to wait for another agent)
• Check on chat state (confirms if chat still valid and which agent(s) assigned)
• Check on agent state (not sure what state you have for agents, but current assignments/logged in status would be good, so we can occasionally check states are synced up)
• Retrieve transcript of conversation
• Retrieve chat session statistics
• Transfer to agent (could be done by using the add agent call on the new agent and remove agent on the old agent).
• Ability to send messages to room programmatically (could be done using a "System" agent)
• Create new agent (to allow automatic synchronisation of agents with external agent database)
• Delete old agent
• Single Sign On, so agents don't have to log in on several systems
• Connect two specified agents together in their own private room so they can consult with each other before transferring
• Control over hosting the agent client interface (allowing embedding into CRM user interfaces)

API Callback (calling into external service from LiveChat)

• New chat request (should contain a unique ID and any useful information known (such as user name, browser language, URL of page where chat requested)
• Chat completed and why (visitor disconnected, timeout, agent terminated etc.)
• Agent assignment successful (could be synchronous result from "add agent to chat" above)
• Agent unassignment successful
• Agent state change (i.e. logging in etc)

[cmcardle75]

One potential solution that doesn't involve much work would be to have our own System agent, which is the only qualified operator, so is always assigned to the chat when it enters the system.

If we can write our own programmatic client for this System user, we would be notified when a new chat session starts (either as we join the implicit chat room, or receive the first message). We can then (at our asynchronous leisure) invite the chosen agent to that implicit waiting room. We can remove them as well. We can detect the leaving of various participants, and even attempts to continue the conversation after the agent has left.

We can even consume the text messages themselves to form a transcript. Whether all the calls required already exist to do this, though is another matter...

[Sing-Li]

This is incredible analysis. Thank you @cmcardle75!

On your System agent idea, how will this supervisory agent implement different call-flows for multiple concurrent calls? Are you thinking that it'll keep a global list of all call flows and maintain state of call-in-progress against those flows? Or are you thinking multiple appearances of the supervisory agent?

[ef-kashif]

@sampaiodiego, @Sing-Li We have similar requirements as described by @cmcardle75.
We came across Rocket.Chat while building a universal chat solution connecting 3rd party chat solutions such as Skype, Skype for Business, FB chat, etc., with Cisco contact center agents.
We were building the solution on ActiveMQ but found Rocket.Chat quite interesting because of the rich feature set supported by APIs. However, the solution lacks some APIs that we need. In addition to the APIs requested by @cmcardle75, we need to do the following:

• Detect a new incoming chat request ==> A push notification (ideally)
• Route the request as a task to a 3rd party routing engine (our Media Routing Engine in this case)
• The engine would then return an Agent ID that'll handle this task
• Add that agent to the Room => via API
  Is there any work in progress on the External Routing API?

[marceloschmidt]

@renatobecker please take a look at this issue and the referenced issue. Make a list of API requests, consolidate, and then close this issue, please? Thanks.

[renatobecker-zz]

Okay, @marceloschmidt.
Thanks.

[renatobecker-zz]

We've created specific issues for each feature described on the issue's description.
All of these features can be found here: https://github.com/orgs/RocketChat/projects/20
If you guys notice that there is any feature missing, please, just let me know.
Thanks.