The driver for this article is not to start a debate on what things need technological prowess to understand versus the logical components of a highly scalable SaaS-based platform. We intend to help you fit a complex system into a logical block in a way that a layperson can understand.
What does API mean?
Let's take an example where you are talking to your friend. If the two of you speak in the same language, it’s convenient for one person to understand what the other is saying.
But imagine having the same discussion with a person who doesn’t speak the language. It seems tricky, right?
Replace the people in these pictures with systems. APIs can be thought of as the communication medium across the system. Let’s take an example. You have two systems; System A is Engati, and System B is a ticketing system. Say you’d like to create a ticket using System B through Engati. To achieve this, both systems need to communicate in one language; They need to follow one API standard.
Now you must be wondering if there are different languages to communicate between these systems. Of course, there are. Similar to how languages like English, French, Italian, and Hindi exist, there are multiple ways to communicate, like HTTP REST, SOAP, GraphQL, Sockets, etc. And just like English is a language that most people try to talk to communicate globally, systems often tend to support REST API-based communication (then again, there is always a group of people who don't like to speak English)!
What is a REST API?
Just like how every language has grammar, syntaxes, and dos and don'ts, communication between systems has its own set of rules. Let's look at the details of the parts of speech/grammar equivalence for a REST API.
Going back to our example of Engati attempting to create a ticket in the ticketing system, that is a create operation. Hence Engati will have to invoke a REST API in the ticketing system. To invoke the API, you would need to know the parts of speech/grammar equivalence, i.e., the URL, Parameters, Request Type (which ideally should be POST), Request Body.
So a logical diagram would look like this:
Similar to how you use a language dictionary to understand the words of the language, we need to look at the documentation of a system to understand the request and the response formats. What details will be sent and what will be received are more specific to each system that we talk to.
The next time you are looking for an integration between two systems, remember that APIs are just two people (systems) talking to each other under all the technical layers.
Engati's extensive documentation page can help you navigate through APIs to create extensive functionality around the platform.
.webp)