Third-Party Bot

The integration between the BOT platform and Webex Connect is setup using webhooks. The platform will provide incoming and outgoing webhooks.

The outgoing webhook will be used to notify the BOT platform of events such as an incoming message from an end customer (if the customer interaction channel is managed by IMI) or an agent’s response.

Adding a BOT Integration

A BOT integration allows Webex Connect to route messages to and from your BOT.

To add a new BOT:

  1. Click Assets > Integrations > Add Integration > Generic Bot.

Figure 1: Add Integrations

  1. Select BOT PLATFORM and click Next.
    Choose IMI BOT to allow Webex Connect to route messages to and from a BOT. Otherwise, choose OTHERS.

Figure 2: Select BOT Platform

  1. For IMI BOT platform, enter a name for the integration and click Next.

Figure 3: Enter Integration Name

  1. (For IMI BOT Only) A BOT endpoint is used to notify your BOT of Webex Connect events via HTTPS POST request using the BOTs access token for verification in every interaction with the BOT.
    In the BOT Endpoint window. Enter a value in BOT's endpoint URL and BOT's access token.
  2. Click Save.

IMI Bot: Bot Endpoint

  1. For Other platform, enter a name for the integration and click Next.
  2. (For Generic BOT only) In the Outbound Webhook window, enter values for the following:
    • Webhook URL: This is used to notify your BOT of Webex Connect events via an HTTPS POST request.
    • Verification Token: The webhook will return this verification token as part of the response to every POST request.

User must configure the Webhook URL on which the BOT will receive the events from Webex Connect. This Webhook will notify Webex Connect of the BOT events via HTTPS POST requests.


Others: Outbound Webhook

  1. Click Verify and then Save.

Using Bot in a Service

To use a BOT in a service,

  1. On the integration list, map the added BOT integration to a service and click Save.

Figure 5: Add Integration to Service

  1. Create a rule with incoming message on the added channel asset as the trigger, to perform one of the following actions:
  • Forward the message to CCSP integration
  • Forward the message to BOT
  • Forward the message to be handled by BOT + CCSP
  1. Select an event from the available list and enter trigger conditions:

Figure 7: Select Event

The Handover event is raised when the BOT decides to handover the chat to a CCSP integration.


Figure 6: Select Trigger Channel

The first message is always received by the BOT, then the CCSP will hold the flag to route all future messages from the same user on that particular channel asset.
All the messages, that is, from the customer or agent, are forwarded to the BOT so that it can collate the data.

Communicating with BOT

  1. After the rule with a BOT, the action is configured in the service, a new message from the customer on the configured rule trigger channel will be sent to the BOT on the configured Webhook, via chat engine.
  2. Chat engine will create a unique conversation ID of type BOT for a unique combination of asset ID, user identifier on the channel, the service, and the BOT.
    While communicating with a BOT, the same conversation ID must be used, unless the BOT chooses to close the conversation.
  3. If the Webhook does not respond within five seconds or there is an error, then a maximum of four retry attempts will occur over the next hour.
  4. If there are five consecutive failures observed, then the Webhook is made temporarily inactive. To reactivate the BOT integration must be edited and Webhook must be re-verified.
  5. With each event, a unique conversation ID parameter is also passed. This conversation ID is used to identify a unique customer conversation; the BOT platform is expected to pass the conversation ID back to the Webex Connect to identify the activity on the same conversation ID.
  6. The BOTs response is received on the Webhook URL that was generated for the added integration.
Conversationid : "", // auto-generated by IMI
ConversationType : "BOT" // if the conversation is of type BOT then only the BOT is expected to send a response
Message : "",
MessageType : "",
Messageid :"",
Channel : "",
Event : "Incoming message",
Timestamp : "YYYY-MM-DD hh:mm:ss.SS", //S in GMT
Conversationid : "",
ConversationType : "BOT"
PostbackPayload : “PAYLOAD VALUE”,
Channel : "FB",
Event : "FB POSTBACK",
Timestamp: "YYYY-MM-DD hh:mm:ss.SS",//in GMT
Conversationid : "",
ConversationType : "BOT"
Messageid :"",
Channel : "",
Event : "Message Delivery",
DeliveryStatus :”Delivered/Failed/Read”,
Description :”Error description”, //only in case of failures
Timestamp: "YYYY-MM-DD hh:mm:ss.SS",//in GMT
eventid : "1001",
conversation_id : "",
message : ""
Messagetype: "",
Timestamp: "", //YYYY-MM-DD hh:mm:ss.SSS in GMT
customparam1 :"",
customparamN: ""
eventid : "1002",//can be event type as the key name and predefined text as value well which ever suits the dev. 
conversation_id : "", 
Timestamp: "", //YYYY-MM-DD hh:mm:ss.SSS in GMT customparam1 :"", 
customparamN: "" 

Conversation Between BOT and CCSP

When a rule is configured for BOT and CCSP, the first message of the conversation is always received by the BOT. Only when the handover event is received from BOT, the subsequent messages from the customer is sent to the CCSP.

The conversation ID with a BOT is the same during all interactions, unless the BOT closes the conversation, whereas, every conversation with the CCSP agent has a new conversation ID, which is closed on chat engine (when an agent closes the conversation).