Service Architecture

The user's frontend requests a chat with a live avatar by calling the publicly available SDK with the required key/token and the required parameters (product name, avatar ID, etc.).
The SaaS backend asks to specify a separate computational resource (called a worker) to create the video, and to create and connect a streaming channel to send and receive media between the user and the worker. Entry into the channel is done through logic in the SDK.
- If there are no idle workers, a wait information is sent back, which the SDK receives and displays on the screen.
The user's voice and the avatar's video are sent and received over that channel. However, if there are any necessary signals, they are sent and received via the SaaS Backend. All of this communication is done through the SDK code.
The video is played and interacted with in the component displayed on the user's frontend by applying the SDK.

Your server will have an API key that is different from the SDK key. This API key is for your server and should not be passed on or disclosed to your customers.
When an End User signs up for a membership on Customer's server, or when they first decide to use the Service, Customer requests and stores an End User ID for that End User on the SaaS server.
When an end user logs in to your server and wants to engage in a avatar conversation, your server validates based on its own business logic whether the user is authorized to engage in the conversation, and then makes an API request to your SaaS backend to issue an End User Token for the conversation. (You can specify usage if needed.)
The customer's server passes the End User Token to the end user's frontend.
The end user's frontend loads the End User Token into the SDK to request a chat connection.

Non-logged-in users can request to chat with a live avatar by calling the public SDK with the SDK key and the required parameters. However, since the SDK code and key are public information, this method is not recommended as it can be used indiscriminately by non-logged-in users. Nevertheless, it can be used on a limited basis for prototypes or users who want to test simple connections. In the future, the SaaS backend will support the following elements to prevent abuse
- Toggle to allow/disallow access using SDK keys
- Quota / Rate Control to prevent indiscriminate use by non-logged-in users, even if you allow access via SDK key.
The recommended method is for non-logged-in users to follow the path in (a) to make a request to the customer's server, which will issue a temporary End User account and token when the conversation is allowed, and then access it in the same way as a logged-in user. When processing the conversation request, your server can either allow/disallow based on its own policies or allow the conversation with a usage to match the policy.

Last updated 1 year ago

The user's frontend requests a chat with a live avatar by calling the publicly available SDK with the required key/token and the required parameters (product name, avatar ID, etc.).
The SaaS backend asks to specify a separate computational resource (called a worker) to create the video, and to create and connect a streaming channel to send and receive media between the user and the worker. Entry into the channel is done through logic in the SDK.
- If there are no idle workers, a wait information is sent back, which the SDK receives and displays on the screen.
The user's voice and the avatar's video are sent and received over that channel. However, if there are any necessary signals, they are sent and received via the SaaS Backend. All of this communication is done through the SDK code.
The video is played and interacted with in the component displayed on the user's frontend by applying the SDK.

Your server will have an API key that is different from the SDK key. This API key is for your server and should not be passed on or disclosed to your customers.
When an End User signs up for a membership on Customer's server, or when they first decide to use the Service, Customer requests and stores an End User ID for that End User on the SaaS server.
When an end user logs in to your server and wants to engage in a avatar conversation, your server validates based on its own business logic whether the user is authorized to engage in the conversation, and then makes an API request to your SaaS backend to issue an End User Token for the conversation. (You can specify usage if needed.)
The customer's server passes the End User Token to the end user's frontend.
The end user's frontend loads the End User Token into the SDK to request a chat connection.

Non-logged-in users can request to chat with a live avatar by calling the public SDK with the SDK key and the required parameters. However, since the SDK code and key are public information, this method is not recommended as it can be used indiscriminately by non-logged-in users. Nevertheless, it can be used on a limited basis for prototypes or users who want to test simple connections. In the future, the SaaS backend will support the following elements to prevent abuse
- Toggle to allow/disallow access using SDK keys
- Quota / Rate Control to prevent indiscriminate use by non-logged-in users, even if you allow access via SDK key.
The recommended method is for non-logged-in users to follow the path in (a) to make a request to the customer's server, which will issue a temporary End User account and token when the conversation is allowed, and then access it in the same way as a logged-in user. When processing the conversation request, your server can either allow/disallow based on its own policies or allow the conversation with a usage to match the policy.