Stay Connected

Our News Centre and Blog is your link to a dynamic network of information, people, and ideas curated by our FX and payments experts.

What on earth is API?
A guide to what it is and isn’t for a person who has never seen a command line

Daniil Saiko September 11, 2018

Many business news sources are crowded these days with articles and white papers on integrations, digital transformations and other technology initiatives. Although for the most part they are insightful, this article will focus on more basic concepts and try to dispel any confusion on what API is for non-technical people who find themselves confronted with technical buzzwords in meetings.

So, according to Wikipedia, API is:

“a set of functions, procedures, methods or classes used by computer programs to request services from the operating system, software libraries or any other service providers running on the computer. A computer programmer uses the API to make application programs.”

APIs are the building blocks of digital economy, use and implementation can vary drastically yet use the same components.

Great, but what does that all mean?

API is how applications talk to each other. And just like a human conversation, it includes a lot of questions and answers, which in APIs are called Requests and Responses. You make your Request to an “endpoint,” which is essentially a small window or a gate into a bigger application.

In simple terms, you can ask an API endpoint a question (Request) and it should give you and answer (Response). A common type of an endpoint is a URL just like the one you see in your browser of choice.

It can look something like . . .

One endpoint has a limited number of questions it can be asked, and a limited number of answers it can produce. When you google something, the Google web page asks the Google API, “what is that?” And Google responds with a list of things that match your search.

Another way to visualize endpoint is to think of them as sockets.

Different types of cord can be plugged into different types of socket, and in turn it can transmit different types of information. So, it has to be a very close match between the endpoint and the API request – otherwise they won’t match and will result in an error.

Going further with the cord analogy, think of how an iPhone uses a special cable that can only transfer certain information (photos, music, etc.) between certain other products. Try plugging that same cable into your air conditioner or a fridge, and nothing happens – for now at least.

Endpoints function as gateways into the larger application and therefore into remainder of the logic and data in that application, which can be vast. But when you make the API request – also known as call the API or make a call – it only produces data relevant to that API request. A good set of APIs is one that does a lot in response to a very simple question. A good example would be getting a price quote for any product, for instance,” how much for 100 widgets”:

  1. It will check if you are even allowed to make such request (authentication)
  2. It will make sure it is within your account limits or region
  3. It will go to an internal data source or ask another service provider using an API for a price
  4. Business logic will add a mark up to the price based on volume
  5. It will return a response with the price

An endpoint often will have a method. These methods are not set in stone, but more developers agree they usually mean roughly the same thing across applications.

A simple example of how they all relate would be an account creation process using the same endpoint, but different methods. Let’s call this imaginary endpoint “”

  1. Firstly, you would make an API call with POST to create a user, submitting all the relevant data
  2. Then you would view the data with a GET
  3. You don’t like the data, so you change it with a PUT
  4. After some time, you want to delete your account, so you submit a DELETE for that account

All four actions used the same API endpoint, but different methods. There are many others, but these are core and many applications stick to set of these four.

Lastly, an API request and response often consist of two parts, headers and the body. Headers consists of all metadata and contextual information and the body consists of actual data. So, in the example above, the POST request would send account data like the name and email in the body, while the header would contain information about the data, such as what data format it’s in, what language encoding is used and any other information necessary to understand the data. Authentication is also often included in the header.


This article uses RESTful API as the basis, there are other protocols and implementations, but this is currently most widely used in web development