How LMS Collaborator integrates with all systems, or what are API and Webhook
According to the official version, an application programming interface (API) is a set of definitions of subroutines, interaction protocols, and tools for creating software. It serves as a bridge that helps developers connect two separate systems and make them into one coherent mechanism.
It sounds very interesting, but to a person who has nothing to do with programming, it is completely incomprehensible.
That’s why we decided to talk to CTO & Co-Founder of LMS Collaborator Oleksandr Slubskyi to get a translation from technical language to human language and finally find out what the application programming interface is and why it is needed.
About the API in simple terms
Imagine that you have come to McDonald’s for your favorite Double Cheeseburger Menu. The kitchen staff doesn’t take your order directly because they are busy frying fries, assembling burgers, and making coffee. If they are distracted by chattering with each new customer, you will have to stand in line for hours.
That’s why you need a kind of intermediary to transfer your order to the kitchen. In our case, this role is played by a self-service terminal or a cashier. As a result, the staff is not distracted from their direct work, and you receive your order within a few minutes – everyone wins.
The API works on the same principle.
This is the intermediary that allows services to interact with each other. For example, an LMS alone cannot send SMS messages to employees to notify them of a new task or test, but mobile operators can. In this case, the API acts as a self-service terminal that helps to establish communication between these systems.
Long ago, this was something new and unusual, but now it is considered a generally recognized standard. One way or another, all services have their own APIs.
Open any application on your phone, for example, Diia. In fact, your gadget has only a user-friendly interface and a minimum of logic, because most of the iceberg lies somewhere on the servers. And with the help of the API, these two parts of the application communicate with each other.
Oleksandr Slubskyi, CTO & Co-Founder LMS Collaborator
Before it appeared, in order to interact with another system, you had to access its database directly, which is not safe from the point of view of data confidentiality. Whereas the API allows you to track who makes this request, how often, whether they have permission to do so, etc. That is, the security of your service is under your direct control.
Besides, all databases are different. The API allows you to receive data and interact with it in the same format. Most people do this, which is why it is convenient. And although the Open API standard is not mandatory, it is still commonly used by default.
Integration with LMS Collaborator
We receive requests for connecting third-party services to a distance learning system almost every week. However, there are two possible scenarios here.
First of all, it all depends on how popular such a request is. If this is not the first similar request in the last few months, we can integrate such functionality directly into the system itself. If it is something so unique that only one client needs it, then they can use our APIs to connect the desired service on their side.
Here’s a real-life example. Let’s say that we were approached by a company that trains staff and wants to receive detailed analytical reports to identify problem areas. The LMS Collaborator stores all the information about employees’ course completion – their progress, results, time, and other metrics. However, to visualize the data, you need a special service, such as Power BI.
It turns out that we have two different platforms – software for creating reports and dashboards, as well as the e-learning system itself.
An example of LMS Collaborator and Power BI integration.
Visualization of Kernel company data
This is where the API comes in.
The task of programmers is to “glue” these systems together. Then the company’s manager will be able to go directly to Power BI and get acquainted with the latest data on employee learning activity, which is periodically extracted from the LMS. To do this, they just need to select the desired dashboard with such key metrics as the number of courses started for a certain period, progress by department, or the rating of the most popular programs.
This is how two different systems are connected into one using the API.
If we understand that a large number of users need this functionality, then the task is described, put on the roadmap, and then we go into development. For example, a client wants to integrate with a telecom provider so that SMS messages can be sent only through Lifecell or Kyivstar. Then we ask these operators for API documentation, set up this integration, and the system sends a request to the provider every time a message needs to be sent to the course students.
So, first of all, this is a story about interaction with another party. Of course, there are services that simply do not have an API. Then we do not integrate with them in any way. But these are mostly exceptions to the rule, because 99% of modern systems work via APIs.
Oleksandr Slubskyi, CTO & Co-Founder LMS Collaborator
In this way, we can connect an unlimited number of third-party services to the distance learning system. Still, most APIs have their own limits, including the number of requests. This is done in order to avoid breaking someone else’s system by mindlessly making millions of requests per second. Therefore, when integrating, the programmer should always keep in mind that the other party cannot be called more often than the set limit.
In addition, the option of setting up the APIs once and forgetting about their existence does not work either. As a rule, updating integrated services does not affect the operation of the LMS in any way. Old APIs are usually left unchanged. But if the updates are significant, we will still get a new address.
In this case, the previous connection continues to be valid for a certain period of time, for example, six months, a year, two years. We, as the party establishing the interaction, should receive notifications of changes, as well as new documentation for reconnection, so we need to monitor this on an ongoing basis.
I would also like to point out that despite a rather popular stereotype that is spreading online, different APIs integrated into one system cannot compete with each other. The only thing they can do is not work for some time because of problems on the other side, but not because of an internal conflict. Such a situation is resolved by a simple, prosaic request to technical support, so you shouldn’t worry about it.
Oleksandr Slubskyi, CTO & Co-Founder LMS Collaborator
Types of APIs
Different sources offer us different categorizations. But the truth is that in general, APIs are divided into only two types – public and private. Everything else is a variation on the theme.
Public APIs are openly available on the web. You don’t need to log in and enter a username or password to get them. As a rule, this is some well-known data, something like the weather. You just go to the site you need and find its API. After integration with your service, it will also be able to show the weather forecast for each day.
For private APIs, you should contact the provider directly. It is up to the vendor to decide whether to provide you with access to the documentation or not. For example, the LMS Collaborator APIs are closed. You can access them only after authorization.
Oleksandr Slubskyi, CTO & Co-Founder LMS Collaborator
As for partner APIs, which are often distinguished as a separate type, they can be classified as private APIs as well. The only difference is that you are given a kind of partner ID. It is more convenient because you do not need to enter your login and password every time, your unique key will be enough. That’s all the differences.
As for which APIs should be preferred, it all depends on the task at hand.
First of all, there is one important thing to understand here. Public APIs are read-only. In other words, you can only receive data. For example, when you have an integration with a payment system, the interaction goes both ways. At the same time, using public APIs, you cannot write down your exchange rate to the NBU – you can only read it.
In addition, they are free, which means that no one guarantees you the stability of their work. So if something doesn’t work, it doesn’t work, what can you do?
Special services such as Zapier, IFTTT, and Integrately, where you can find and combine different APIs, also deserve special attention. These are kind of intermediate tools that essentially contact a second party instead of you. They are convenient, but keep in mind that free options, unlike paid ones, have rather limited functionality.
Of course, it’s better to negotiate directly with the end party, but this is more the level of large companies: they are very security-conscious and consider such services an additional risk, so they don’t want to give their data there.
As for smaller organizations, this is a common practice for them. This way, they save money on hiring programmers. A manager has taken a course on how to use such a service and in a day can do what a developer would have taken a week to do from scratch, and it would have cost a pretty penny.
So it all depends on the ultimate goal, the size of the company, and its internal policies.
Oleksandr Slubskyi, CTO & Co-Founder LMS Collaborator
Potential threats
Although the API is considered a more secure format than the one that existed several decades ago, when you had to access the database directly, it also has its drawbacks.
Theoretically, the same hacker can lure out the login and password of the client you’ve integrated with and log in that way. However, this is more about social engineering, i.e., fraud, but it often works. In fact, through the API, an attacker can do everything that a client can do through a browser, so this is a pretty serious problem.
Oleksandr Slubskyi, CTO & Co-Founder LMS Collaborator
Again, limiting the number of requests is also part of security. The logic here is simple. Any service can go down if it receives too many calls per second. The API, in turn, allows you to limit the party that sends it requests, thereby securing the operation of the entire system.
API vs Webhook – what is the difference?
These two concepts are often confused. It’s not surprising, because they are essentially two mirror processes. And while the API allows the client to call our eLearning system, the Webhook, on the contrary, gives us the opportunity to access it.
Implementation of Webhook on the platform
Why is this necessary?
Of course, you can, for example, make an API request every minute to find out if any of your students have completed your course. This will also work, but why complicate things? After all, you can call the LMS only when someone completes a certain course, that is, set up a condition to activate the action. This is exactly how Webhook works.
However, it should also be linked to some APIs that are written on the client side. This is a machine-to-machine interaction between two systems, in which people are not involved. In other words, Webhook complements the API, allowing you to call it whenever the client needs it.
Oleksandr Slubskyi, CTO & Co-Founder LMS Collaborator
In practice, it looks like this.
Our customer needed us to call his API every time a message was sent to someone. They wanted his employees to receive notifications about the training process not by email or phone, but through other internal channels.
In this case, all we need to do is call its side when any message is sent within the LMS, such as an appointment to a course. For this purpose, we use a Webhook, which looks like a regular URL. We call it every time a trigger is triggered, that is, when one of the students receives a message, and then the customer interacts with it at his or her own discretion.
There is no other way to implement it. We can’t send messages directly to the API because we don’t know where to go. But Webhook allows us to do this when a trigger is triggered. If we hadn’t implemented this feature, we would have had to collect and store these notifications somewhere, and the client would have had to make requests every few minutes to check whether the status has changed since their last request.
In other respects, the mechanics of API and Webhook are quite similar.
This also applies to cases where server-side events occur too often. In this case, the queue and, accordingly, the response time to messages will grow, and requests will accumulate until our client gradually processes them or stops working due to overload. This is why there are restrictions on the number of calls, which were mentioned earlier.
In other words, just as we can hack the other party if we send too many requests, so they can hack us.
Oleksandr Slubskyi, CTO & Co-Founder LMS Collaborator
