Management API
The Management API allows you to fully integrate all functions within the Syntphony CAI's Cockpit into your own service or system, seamlessly integrating Syntphony CAI's system within your solution.
Audience
The Management API covers 100% of the functions that the cockpit has to offer to manage your virtual agents and their content. The following documentation targets two people:
Technical teams who intend to either partially or fully integrate the cockpit's functions within your own system
Technical teams attempting to fully understand the behavior of Syntphony CAI.
While one may find that reintegrating all of Syntphony CAI's cockpit functions pointless, this API offers you the possibility of allowing your team to access specific features from Syntphony CAI without the need of granting them access to Syntphony CAI's cockpit, by accessing them directly from your website with a generic user token.
For instance, you could consume the data used in the Dashboard API to have your Virtual Agent's usage reports exposed on your website, or to enable the training option in a button on your website, in which someone without Syntphony CAI access could use.
How to use this API
Authentication
Authentication must be handled following the OAuth2 Bearer Token protocol, where one must authenticate with a valid, expirable token.
Once obtained, the access token must be sent in your header ‘Authorization’ as the string: “Bearer {{access_token}}” on every request.
While the Conversation API allows you to use either a User Token or Client Credentials, the methods found in this documentation requires you to use User Token.
Obtaining your Authentication Token
To generate a token, make a request on the following endpoint:
POST
Request Body
Content-Type is ‘x-www-form-urlencoded’. Username and password are your own credentials; client_id and grant_type are fixed texts. If you lack credentials, ask your administrator to issue a valid user to your environment.
Sample Response Body
While there are several, default fields that you may map from the OAuth2 response body, we recommend you to map those, as they are the only ones you will need to use.
Name | Type | Description |
access_token | String | Your bearer token. Can be as long as 800 characters. |
expires_in | Integer | Lifetime of your token, in seconds. |
refresh_expires_in | Integer | Lifetime of your refresh token, in seconds. |
refresh_token | String | Your refresh token, used to renew your token. (See below) |
Sample response
Authentication Token Renewal
Authentication tokens may expire, as indicated by the ‘expires_in’ field from the token generation response. When it does so, you may still renew it without reentering credentials, by calling the same endpoint, but with the following request body:
Renewal Request Body
Once again, Content-Type is ‘x-www-form-urlencoded’. If your refresh_token has also expired (indicated by the field ‘refresh_expires_in’), you are required to generate a new token by reentering the client credentials.
Token Access Restriction
Authentication tokens generated through user/password acceess will reflect whichever configuration you have for the user. You may properly configure your user so that is has restricted access on any given environment or bot. By restricting it's access, you may ensure that the token used for one of your bots has no access to any other Syntphony CAI resource from your organization.
This means that you could either fully integrate a login function on your services that internally log into Syntphony CAI, or have a group of pre-set accounts in which your functions use.
You could, for instance, have a preset Reader-only token with restricted access to some or your users, and another preset user with Admin access for other users with full access.
Endpoints
The API endpoints differ from those you use to log in the Syntphony CAI cockpit.
In order to use this API, we ask that you open a ticket and request access to your Management API base URLs, which will be at least 2, but may be more.
We have a separate Admin base URL, and an individual base URL for each of our instances. Should you have a single instance, there is no need for disambiguation. If you have more than one, the Admin API also has methods to discern which instance you want for each environment.
All of the endpoints on this documentation follow this pattern:
Field | Value |
---|---|
BASE_URL | The base URL your service refers to. YOu may request this value through a ticket. |
API_SUBPATH | The API subpath. Each page here lists a subpath, and all methods found within must use this subpath. |
METHOD_ENDPOINT | The method endpoint, found at each request. |
So if your BASE_URL is 'my-service-admin.eva.bot', your API_SUBPATH is 'eva-user' and your METHOD_ENDPOINT is '/org/{orgUUID}/users', your final endpoint will look like the following:
Recommended Practices
While you can learn about Syntphony CAI by reading this documentation, we strongly recommend that any teams attempting to integrate our API into your system actually use the eva-cockpit in a development environment, and familiarize with each used concept.
All Models and APIs are named accordingly to the names seen on the cockpit - the sole exception being "Bots" which are referred to as "Virtual Agents".
Understanding the purpose for each of those elements and their connections by using the cockpit will strongly assist you in identifying what are the relevant integrations to achieve a specific objective, and what can be ignored.
We also recommend you to ensure your traffic is properly cryptographed to ensure you are not exposing keys to your organization and environments. By requesting the access to the Management API, you are declaring you will ensure that traffic data will be properly secured by you.
Last updated