What is an integration?
It is the possibility to link or connect the AgentBot service with a client service. For this integration to be possible, we use dynamic information from this other system. To do so, we need have all the necessary documentation on how to access the content.
Integrations via Web Service
Integrations are possible via Web Service technology, which allows organizations to share information with other systems and exchange data without having to know the details of their information systems.
Integrations can be made to any type of Web Service, regardless of the type of technology used for sending and receiving data (e.g., Rest or Soap).
The client provides the information on how they want to do this: documentation, access, methodologies, forms, and any other necessary information to integrate these services, whether proprietary or provided by a third party.
Follow the steps below for the integration to be completed successfully:
1. Requirements are sent to the client.
2. The client sends these requirements to the technical department.
3. Receipt of documentation and requirements by AgentBot's technical department, followed by analysis and implementation.
The development time for a Web Service is approximately one week, or less, depending on each case and data complexity.
For example, if you require authentication methodologies or VPN configurations, integration may take longer.
There are two ways to use the Web Service in the agent:
1. Proactive: The user is offered a list of available options as soon as they enter the bot. The user does not have to enter a query for the interaction to start.
2. On demand: The user enters a query that activates the service.
Requirements for Creating a Technical Integration
Third-party API Integrations
AgentBot allows any type of integration with third-party APIs, according to the client's needs. To assist Aivo in developing these integrations, you will need to provide the following information:
Third-party service data: Each of the third-party API services to be called goes hand-in-hand with the endpoint to be called. These must be presented in a clear and precise manner, so that each integration with the service can be tested correctly. The following formats are compatible:
- Apiary (recommended).
- Postman Collection.
For each integration, we will need:
1.The query that will trigger the integration
2.The routes/endpoints/service to be used for responding
3.Definition of the possible scenarios (it is important to document each of the possible scenarios the user will go through):
- Data to be used by Aivo for each scenario and for testing.
- An example of each endpoint as a curl command.
- The answer to be received from each service in all cases.
We recommend using Flow Charts showing the entire process, step-by-step, and the services that are called during the process.
The information requested is necessary to avoid delays in the integration development. We need to know:
- Types of data to be sent.
- Types of data to be received.
- Formats for sending: JSON, Arrays, XML.
- Formats for receiving: JSON, Arrays, XML.
For a successful connection to the services, we need to know:
- If there is some kind of network security, we will need to:
- If a test environment is available for testing.
- If services will require some kind of authentication, please indicate:
+The type of authentication to be used.
+Send credentials of the available environments.
Sometimes, third party services require specific settings to allow access to Agentbot. It is necessary for each service provider to keep them active and accessible when testing.
Examples of the Required Documentation
Service Endpoint - Swagger:
The documentation is divided by flow, and each flow has service endpoints, data to be sent, data to be received, service concept, types of data sent and received, as well as how they are used; for example:
1.Swagger allows you to specify the sending method and the endpoint plug-in.
2.Service implementation notes
3.The answer to be received from the service
4.JSON to be sent or the format for sending
5.Parameters for upload without going through the structure
6.The different messages to be received, such as Curl, endpoint, response body, etc.
7.Swagger allows for direct testing, either by entering the details or via the JSON sent.
Finally, a flow chart has been provided as an example, to show the process from start to finish, each of the possible cases, decision-making, and services to be called. This methodology allows both, the client and the developer, to have a broad vision of the procedure to be followed and the validations to be performed.