Using a license when syncing via API

Sergey Aleksandrovich,
This is a moot point and not a bug.
OneBox OS is built in such a way that OneBox OS is the API through which the OneBox interface works.
You just call this API via REST, and OneBox itself calls the same API via direct call.
Therefore, the internal API does not understand the difference: this user received a token through the REST API, or a real person climbs boxing behind him.
We had to do this for several reasons:
1. so that a cunning user cannot get a token through the API, and then substitute it in the browser (via js-login-layer) and use more simultaneous tokens than he is supposed to.
2. for the cloud, requests to the API create a much larger load on the infrastructure than a regular user, so I made the decision "let the API eat up licenses." This is much better than charging API requests (as 99% of all cloud servers do).
I understand that argument 2 is good for the cloud, but bad for the box.
If we impose at this point the condition that OneBox is more interested in cloud users, then technically it is not profitable for us to make one condition for the boxes, and the second for the cloud. In simple words: since the code is the same and we will not separate the branches, then the API will also consume the license on the box.

Maksim,
I realized that the business model for selling a cloud service is a higher priority for you. It's your right. But boxed users remain your customers, even if they are less loved.
The essence of synchronization is uninterrupted access to data in real time. With such an architecture, even if we buy one more, two or more licenses, there may come a time when all the licenses will be occupied by employees. And in this case, there will still be moments when the API is not available. We cannot constantly monitor that this license is not occupied by employees. Otherwise, you get "automation in manual mode."
The current situation needs to be addressed as we cannot complete the integration without continuous access to the API. The meaning of automating activities is then simply lost.
Our suggestion is to create a "non-user" license and reserve it purely for synchronization.

Sergey Aleksandrovich,
we are unable to comply with your request at this time. Simply because our goal is the cloud, and we do not spray on everything else. Yes, it's tough, but that's my way of thinking: I'm moving only to one point, and all other opportunities or inconveniences that do not lead to movement to this point are of no interest to me.
Now you have two options:
Method 1. Understand that the API takes a license and take it into account (and, as an option, buy another one for this case)
Method 2. Use the API on behalf of the current employee by checking the "Allow working with dynamic IP" box.

Maksim,
The options that you suggested will not work as a solution to the issue. These are half measures. Crutches. What is needed is the stability of the system.
We contacted your project two years ago. Having gone through water, fire and copper pipes, having invested a lot of money and energy - we have set up work through your program, which helps us build a business. Some of the improvements that we have implemented are used in CRM One Box by all valid users.
Stable access to the API is not my whim. This is a necessity dictated by technology. We, as a client, do not care where you are moving. It is necessary to solve the problem, and not to throw it off from a sick head to a healthy one. For your employees, the solution to this problem (in the format I suggested in the previous post) is three lines of code.
In the long run, you will bring much more value by resolving such embarrassments in favor of the client. This will pay off with an increase in loyalty and savings on advertising, due to the work of word of mouth. The business-entrepreneurial community is quite close. Each satisfied customer brings another five, or even ten. Each dissatisfied person dissuades the same number of potential customers from the product.
We are responsible for those who have been tamed (c). Antoine de Saint-Exupery

Sergey Aleksandrovich,
The OneBox API consumes 1 license key because the API is exactly the same user (login=restapi).
It has nothing to do with API access stability.
In fact, this whole topic is about ways to get me to give you (and other users) a +1 license for free, because this is the only way to make sure that the API does not eat the license.
The OneBox business is not about improvements and support, but about making money on renting software and selling licenses. And I will not do anything that reduces this income, even at the cost of negative or positive feedback. This is not "disrespect for users", this is a business model: if you choose between "doing bad for yourself, but good for someone" - then I do not agree to this.

Maksim,
It's not about buying a license: even if we buy one, two, three licenses, we still have to monitor users online manually. We have x licenses, but x + 5 users (not employees, just CRM users). When the API user is offline, synchronization will not work. The point is to get rid of manual work and process automation.
The stability issue can be resolved if the "API user" is pinned online so that his session does not end. Can this be implemented?

Maxim, is it possible to make a user "unbeatable"? that is, so that it always stays online?

Answer the question above

I can offer a setting in restapi that will allow you to randomly throw out the user (or the last one in activity) and the user for the API will become online and execute the request

How can I contact you to discuss the implementation of this setting?

This setting is already there, look in the application settings for api v2