Custom Chatbot Engine
Setup
To enable a custom engine you have to adapt to the Virbe request/response schema, which is described below. You might want to use one of our boilerplate projects as a reference.
(Python) FastAPI boilerplate project
Schema
RoomMessageRequest
id
- this is a unique message identifier - you can use it as thereplyTo
field when posting asynchronously to the roomendUserId
- this is a unique identifier or the user that posted to a particular room conversation - it persists through multiple conversations as long as the user allows for that eg. cleaning a browser cache will clear this value when using a web widget. You might want to implement your own caching mechanism when using our SDKs.room
- this object contains all the information of the created Room conversation.location
- this object contains all the information about the touchpoint that End User is interacting from:name
- it contains the name of the location you've created in the Virbe Dashboard for your own instance or one of the prebuilt touch-points names:Dashboard, VirbeSpace, Mobile, LivePreview
channel
- defines the type of location created in the Virbe Dashboard:Predefined Channels:
LivePreview, Dashboard, Mobile, VirbeSpace
User Registered Channels:
Web, Kiosk, Widget, Unity, Unreal
action
- this object is the one you need to check to implement your own logic for handlingtext
- this is main object you want to analyze and react to in your enginetext
- this contains the text recognized by Speech Recognition or the text written by end user to your Virbelanguage
- this contains the language recognized by Speech Recognition or the language set in the touchpoint configuration
endUserStore
- this object is passed if end user submits the input formkey
- key to store your value undervalue
- value to store
namedAction
- this is the field which is used for signals & triggers eg. widget open, app launch, face detection in the Metahuman Kiosk, QR Code scan etc. You might want to implement your own logic of reacting to this kind of eventsname
- name of the trigger:widget_open, app_launch, face_detected, being_defocus, being_focus
value
- additional string value eg. describe your payload type here to parse it properlyvalueJson
- additional Json object passed through your implementation eg. IoT sensors values
roomStore
- you don't need to react to it most of the times unless you want to store a specific key/value pair when the SDK is starting eg. you want to write and store specific value during new room conversation creationkey
- key to store your value undervalue
- value to store
RoomMessageResponse
If you want your Virbe to speak out loud you need to respond with text
action in the schema.
Responding with Text - Make sure to respond with the following schema
Responding with Text and UI components
Responding with text and storing user email to the EndUserStore. Check out the documentation how to invoke an integration pipeline (Hubspot, ActiveCampaign) or a custom webhook call when EndUserStore key/value pair is stored
Asynchronous Room Message
Asynchronous communication is a perfect solution to improve UX when you have a long-running chain logic for LLMs (eg. ChatGPT) or human-handover scenarios.
Acquire
Room Actions Api Key
from the Virbe Dashboard - you will find it on the Conversation Engine tab eg. https://your-virbe-dashboard.virbe.app/dashboard/conversation-engine
React to RoomMessageRequest by creating a task that will be processed asynchronously eg. in a separate thread pool or queue.
Use
RoomMessageIngest
schema to sendPOST
request to the room asynchronously using the following endpoint:
https://{your-virbe-dashboard-url}/api/v1/rooms/{request-room-id}/messages/api
Request Body Schema:
You can post multiple responses to one request if you want to. To send other actions check the section above.
For a more detailed example scenario check out the sample code in our Github:
Human handover
Stop responding automatically and pass all RoomMessageRequest to your system eg. Slack channel or your own software
Start posting asynchronously to the room conversation using asynchronous messages described in the previous section
Last updated