REST Reference Guide

General

In this page you will find all of the MyLINK Connect endpoints exposed by the Custom Channel. All endpoints are related to your integration endpoint, as specified in the general channel settings.

Authorization And Security

Unless Simplified Authorization Scheme is enabled, each request to the custom channel must include a valid bot-level authorization token. Please refer to this section to know how to generate one. Once obtained, the authorization token must be specified in a standard Authorization header.

When using Simplified Authorization Scheme, the Authorization header bearer value can simply contain the API Key of the bot.

While Simplified Authorization Scheme simplifies integration mechanism it also opens to potentially unwanted security concerns and it should be considered only as a last resort where auth token handling becomes too difficult. If you are integrating with MyLINK Connect Custom Channel, we strongly recommend using the Bot Level Authorization token mechanism.

Additionally, each to you custom endpoint will contain an Authorization header set to the source bot API Secret. Please ensure that your endpoint correctly filters any request that doesn't contain the correct value.

Accessing Bot Configuration

You chatbot basic configuration, as specified in your settings, can be retrieved using the following route:

curl -X GET <INTEGRATION ENDPOINT>/custom/config \
  -H 'Authorization: Bearer [AuthToken]' \

Since this is a global configuration, you don't need to specify the current user-id here. MyLINK Connect reply to this request will be similar to this one:

{
    "Name": "My Awesome Bot",
    "EnableTypeSpeed": true,
    "WordsPerMinute": 800,
    "Avatar": "https://...",
    "Version": 96,
    "DefaultBehaviour": {
        "Name": "My Top Behaviour",
        "APIKey": "[Behaviour API Key]"
    }
}

Chatting on the Custom Channel

Each message call that is made to the Custom Channel API can contain a UserId field.

This field is used by MyLINK Connect to uniquely identify a user conversation for your current bot. If no value is supplied, MyLINK Connect will create a unique UserId for you. The UserId value is threated as a string and can contain any value.

Initiating Chat

The fist connection to your chatbot chat must be done by calling the chat endpoint using the previously specified headers.

By issuing the RESET command, the conversation will be reset to the starting point. If the UserId is specified in this call, the conversation will be reset but historic conversation will be kept in the MyLINKConnect conversation history interface.

curl -X POST \
  <INTEGRATION ENDPOINT>/custom/chat \
  -H 'Authorization: Bearer [AuthToken]' \
  -H 'Content-Type: application/json' \
  -d '{
        "UserId":"<user-id>",
	"Command":"RESET"
   }'

If you wish instead to continue a previous conversation with a know user you can add the READY command to the request as below. In this case, MyLINKConnect will not reset the conversation and return the full history as first reply.

curl -X POST \
  <INTEGRATION ENDPOINT>/custom/chat \
  -H 'Authorization: Bearer [AuthToken]' \
  -H 'Content-Type: application/json' \
  -d '{
        "UserId":"<user-id>",
	"Command":"READY"
  }'

If you expect the user to be triggering your bot with a specific keyword, you can skip standard initiation and go directly to the chat flow. In this scenario, you should expect a start user text in the flow and trigger a response accordingly.

A successful reply from MyLINKConnect may look like this:

{
    "Parts": [
        {
            "Type": 0,
            "Text": "Hello...I am Xenioo!",
            "TypeDelay": 300,
            "BehaviourName": "New Bot Behaviour",
            "InteractionName": "Start Interaction",
            "Parts": []
        }
    ],
    "UserId": "<user-id>",
    "Creation": "2018-10-05T14:43:43.7057755+01:00",
    "EnableUserChat": true,
    "ControlType": 0
}

The reply response has the following parts:

Each part may contain different fields, depending on the type. All general fields are as follows:

The type parameter is a number representing different types of contents. Refer to the table below for a full list of all possible types.

Values are not fully sequential as some of the contents are reserved for internal use by the MyLINK Connect engine. The missing values should not be expected in a standard parts reply.

Chatting

Once the chat control is given to the user, he can interact with your chatbot in two ways: executing a command or saying something (sending a text).

After acquiring the user input, you can relay it to MyLINKConnect using the same connection endpoint, with the following syntax:

curl -X POST \
  <INTEGRATION ENDPOINT>/custom/chat \
  -H 'Authorization: Bearer [AuthToken]' \
  -H 'Content-Type: application/json' \
  -d '{
        "UserId":"<user-id>",
  	"Text":"Hello there!"
  }'

Depending on how you've implemented your chatbot reactions and interactions the answer may change but will always be compliant to the previous reply fields. If your user has instead any mean to click on chat buttons you've implemented or on Carousel contents you must forward to MyLINKConnect the command payload as follows:

curl -X POST \
  <INTEGRATION ENDPOINT>/custom/chat \
  -H 'Authorization: Bearer [AuthToken]' \
  -H 'Content-Type: application/json' \
  -d '{ 
        "UserId":"<user-id>",
        "Command":"3131292d-945e-4b6b-9f78-7f5eacebf5b6" 
    }'

Command payloads are always GUID values generated by MyLINK Connect. If the command payload is recognized, the command will trigger and the conversation continue, according to the flow you've designed.

Chatting on other channels

The chat command can be used to send messages from a third party platform to an existing MyLINK Connect conversation on any published channel. When invoking the endpoint, if user-id is related to an existing user-id for the selected chatbot, the related conversation will be used and the message sent on the associated channel.

Additionally, you can use the <DIRECTION> header parameter to indicate the direction of the message according to the table below. Leaving the parameter empty will by default assign the supplied text to the user.

The <CHANNEL> parameter is required and identifies the name of the channel you wish to target. Channel names are case insensitive and are equal to the "channel" variable associated with the conversation.

curl -X POST \
  <INTEGRATION ENDPOINT>/custom/chat/<CHANNEL>/<DIRECTION> \
  -H 'Authorization: Bearer [AuthToken]' \
  -H 'Content-Type: application/json' \
  -d '{ 
        "UserId":"your-user-id", 
        "Text":"hello!"
   }'

Since chatting on other channels can be used to simulate the chatbot talking, it also possible to send more complex content to your users target channel by using the same syntax of standard chatbot outgoing messages.

The example below will send a text bubble and a button to Telegram as an operator

curl -X POST \
  <INTEGRATION ENDPOINT>/custom/chat/Telegram/OPERATOR \
  -H 'Authorization: Bearer [AuthToken]' \
  -H 'Content-Type: application/json' \
  -d '{
    "UserId":"user id",
    "Parts":[
        {
            "Type":0,
            "Text":"Hello there!"
        },
        {
            "Type":1,
            "Command":"my button id",
            "Text":"Click me!"
        }
    ]
}'

Please note that since it has been built by the request, the above button will not be recognized by MyLINK Connect and the click will trigger a fallback. You can adjust your flow to expect the button text and still send it as a chat text when the user clicks it.

If the Include All Channels Conversations option is enabled your hook will also receive real-time notification of users and chatbot messages to the custom webhook endpoint. All these additional real-time notification will count as an additional action message for the active account.

Conversation Position

You can freely change the current conversation position using the ForcedBehaviour and ForcedInteraction parameters as described below:

curl -X POST \
  <INTEGRATION ENDPOINT>/custom/chat \
  -H 'Authorization: Bearer [AuthToken]' \
  -H 'Content-Type: application/json' \
  -d '{ 
        "UserId":"<userid>",
        "ForcedBehaviour":"My Custom Behaviour", 
        "ForcedInteraction":"My Custom Interaction"
   }'

The result of this call will redirect the conversation to the specified Behavior and Interaction and execute its contents (exactly like a standard Go To Action). If the behavior or the interaction cannot be found the flow will redirect to the start interaction of the start behaviour.

The current conversation position can be instead retrieved with the following route:

curl -X GET \
  <INTEGRATION ENDPOINT>/context/<userid> \
  -H 'Authorization: Bearer [AuthToken]' \

Conversation position can only be changed when the conversation is handled by Xenioo. Taken over conversations will ignore this command.

Handling Variables and Tags

During the conversation you can use the custom channel to update variables and tags in real-time. These variables will be immediately acquired by your flow and can be used by your bot flow to make decisions or display data.

The following call will create (or update, if it exists) a variable named "my_variable" and add a tag named "VIPUSER".

curl -X POST \
  <INTEGRATION ENDPOINT>/custom/chat \
  -H 'Authorization: Bearer [AuthToken]' \
  -H 'Content-Type: application/json' \
  -d '{
	"UserId":"<user-id>",
	"InputVariables":[
		{
			"Name":"my_variable",
			"Value":"some_value"
		}
	]
	"InputTags":[
		"VIPUSER"
	]
}'

As you many have noticed the endpoint for Variables and Tag updates is the same of the standard chat. Chat updates and data updates can be sent in the very same payload. In the following example, we receive a text from the user and we also forward the same data as above:

curl -X POST \
  <INTEGRATION ENDPOINT>/custom/chat \
  -H 'Authorization: Bearer [AuthToken]' \
  -H 'Content-Type: application/json' \
  -d '{
	"UserId":"<user-id>",
	"Text":"Hello there!",
	"InputVariables":[
		{
			"Name":"my_variable",
			"Value":"some_value"
		}
	]
	"InputTags":[
		"VIPUSER"
	]
}'

Retrieving single values

Variables, tags and privacy flag values can be accessed anytime by using the following call:

curl -X GET <INTEGRATION ENDPOINT>/custom/values/<userid>/<type>/<name> \
  -H 'Authorization: Bearer [AuthToken]' \

The userid parameter identifies the unique id of the user you wish to target. Userid are unique regardless of channel: you can use this call to retrieve data associated to Custom Channel and any other published channel.

The type parameter can be any of the following:

As an example, the following call will retrieve the value of the specified user user_telephone_number variable:

curl -X GET \
  <INTEGRATION ENDPOINT>/custom/values/<userid>/variable/user_telephone_number \
  -H 'Authorization: Bearer [AuthToken]' \

If successful, the request will answer with the value of the variable or, if a tag or privacy flag is required, with either true or false.

{
    "Value": "+555-555-555"
}

Retrieving all values

If your integration needs a full snapshot of the current conversation values, you can use the following route to receive them all:

curl -X GET <INTEGRATION ENDPOINT>/custom/values/<userid> \
  -H 'Authorization: Bearer [AuthToken]' \

Connect reply will contain all of the currently valued variables, tags, Privacy flags and context in the following format:

{
    "Variables": [
        {
            "Name": "user_name",
            "Value": "User 1372503197"
        },
        [...]
    ],
    "Tags": [
        "new_user"
    ],
    "PrivacyFlags": [
        {
            "Name": "personal_data_processing",
            "Enabled": false
        },
        [...]
    ]
}

Conversation Status

When a conversation with a bot is taken over or handed over it changes of state. You can get or set the state of any conversation using Custom Channel.

Current state

Any time during conversation you can retrive the state of a conversation by using the following route:

curl -X GET <INTEGRATION ENDPOINT>/custom/state/<userid> \
  -H 'Authorization: Bearer [AuthToken]' \

MyLINK Connect reply will contain the current conversation state. If the user is banned, also the expiration day of the ban and the associated message will be returned.

{
    "ControlState": <state>,
    "BanExpires": "...",
    "BanMessage": "...",
}

The state value returned by the request can be one of the following

Updating Current State

Using Custom Channel you can change a conversation state in real-time. Status updates may also affect Shared Conversations, depending on the parameters supplied.

The following route can be used to update a conversation state:

curl -X PUT <INTEGRATION ENDPOINT>/custom/state/<userid>/<state>/<mode>/<operator> \
  -H 'Authorization: Bearer [AuthToken]' \

The state parameter can be one of the following:

When handing over the conversation to MyLINK Connect, the mode parameter can be used to specify how Shared Conversations URL are handled:

If the mode parameter does not apply to the state you're setting, use a * (asterisk).

The operator parameter must refer to a valid operator email. User a * (asterisk) to allow for any operator or to simply not specify one when the call does not require it.

Last updated