help.chat-api.com

How do I create and configure a new messengers API chain?

To create a new API Chain, you need to go to the section of the same name in your Chat API Personal Account. Select the "Add a new Chain" section. For your convenience, the page view can be moderated and output Chains in a list or table.

Next, select one of the following templates:

1 - Default template - Standard API chain template with basic settings. You can choose additional links (tasks) of the chain yourself;
2 - Google translate template - A chain template with two-way translation of messages via Google Translate. To work with this chain, you need to configure Google Key to access the Google API;
3 - Menubot template - A chain template with connection to the capabilities of our free Chatbot. To work with this chain, you need to have a customized MenuBot template. It is possible to do this in the corresponding section of your personal account.
4 - Google sheets template - A chain template for saving data in Google tables. Requires the creation of an OAuth2 key and passing the authorization stage.

Each presented version of the chain template is already set up to work, you just need to fill in the necessary fields.

Further configuration of the chain :

Address and token in your personal account

It is necessary to change the former request to your instance to this address.
Key or token - specify this token instead of the previous token that was used to access the instance.

The "Show logs" button - "update logs" - shows or hides all available logs on the page. Logs appear after a request to the chains. Logs are automatically updated every 2-3 minutes. The update logs button forcibly updates them at your request.

Server statuses

These statuses are presented in the upper right corner of each link. They display the working situation of the link, signal errors or the need for additional settings.

From left to right:

1 – "Error in server configuration" - indicates that the link is configured incorrectly. Go through the setup steps again, something was missed;
2 - "Error when executing a request to the server" - view the logs, the error occurred during the execution of the code on the server;
3 – "Everything works fine" - if this icon is lit, then there is nothing more to worry about. You did everything right;
4 – "There are logs to display" - logs for viewing are available to you.

Further adjustment of the link, step-by-step elements

Each link contains a number of settings that need to be performed. If the previous configuration step was performed incorrectly, it will light up red and all subsequent steps will not be available.

If everything is done correctly, the icon turns green. You can proceed with setting up the next section.

Statistical fields

Data that should remain unchanged during the operation of the chain. Often it is an API key for access, which should not change. The data can easily be made dynamic, for this there is a button "Make dynamic".

Dynamic fields

The data that we need to isolate from the general flow, most often they can be found during the test in the logs. The shared data pool consists of what we previously saved in the chain. All parameters of the initial request are immediately saved to the shared pool, for example, a regular request to an instance contains "Body" and "InstanceID", if we repeat the same request to the chains, then we can save this data using the same parameters. Access to deeper queries is carried out through the notation `.' for example, the instance's webhook sends us data of the form:

To access the message text, we must specify "messages.0.body" in the dynamic data. You can also write `...` in this field, which means that all possible values will be accepted in the selected field. On the right, you can notice the “make static" button, which will convert the field to static.

Configuring Requests

This section will help you set up the process and format of sending requests through criteria such as the number of repeated requests and pauses between them.

Timeout – how many milliseconds a response from the chain link server will be expected. By default, the response is expected to be 6000 milliseconds.

Number of repeated requests - if the chains consider the request unsuccessful, then you can specify the number of repeated requests to the server. A total of 1 to 5 attempts are available.

Ignore errors – By default, chains stop working if an error occurs on the request execution path. If it is important for you that the chain does not stop the execution of links, then specify this parameter.

Execution condition

This stage determines the conditions under which the selected link will start. This is useful when it is important to filter which requests will be processed by the link, and which can be ignored. For example, processing only incoming text messages. In some templates, the execution conditions are already initially present. The template with Google Translator processes only simple text messages to avoid translating, say, the url of an image or other non-format messages.

- In the first section, as in the dynamic field, we specify where the value will be taken from.
- In the second, we specify the type of data that we expect to receive.
– In the third - comparison.
- In the fourth, we specify the value with which the comparison will be carried out. The section can be left empty for comparison with "emptiness".

For example, if the body in this example is NOT empty, then the link will start

But if the body turns out to be empty, then the link will not start.

 

Information about setting up middle links (available APIs and Web applications) You can find here - Setting up the middle links.

Information about setting up a lower link (instance) here - Setting up an instance.

Was this article helpful?

Your opinion will be used to improve the content of the article

The Most Multifunctional API Provider

Chat API has been operating since 2015 and is one of the first and largest providers in Eastern Europe.

Here are some curious and important figures:

  • We have tremendous expertise in docker container management at scale with an SLA of 99.5+%;
  • Chat API involves in its work more than 200 servers, with the ability to quickly connect another 100;
  • 3200 cores and 25 terabytes of RAM;
  • 200+ methods and features that keep adding;
  • Highload system, Up Time servers 99.9%;
  • Support 24\7;
Get access to the API