Understanding APIs and how they impact your business

We hear a lot about partnerships in our ecosystem, one Fintech is collaborating with the other to provide a new solution and have you ever asked how? Or maybe why?

In this article, we will discuss “how” partnerships between two or more Fintechs come to be, beyond document signing ceremonies, handshakes and pictures posted.

What is an API?

The full meaning of an API is Application Programmable Interface, this is a set of clearly defined methods of communication between various software components. Most tech companies build APIs for internal use and for external consumers. A typical example is your Uber application where you have Google maps for navigation, Uber and Google are two different companies however Uber is leveraging Google Maps APIs to service their customers.

There are various types of APIs released by companies leveraging technology. Below are API categories;

For this article, we will be focusing on APIs for external customers. There are governances, securities and

authentications around these APIs as businesses do not want to expose their services to bad actors or targeted malicious agents. Also, APIs power a front-end (user interface), however, it doesn’t necessarily need an interface. There are various platforms for testing and documenting APIs, a simple example is Swagger ui, and Postman, these can be used to display documentation and test APIs.

For public APIs, they must be;

1. Well documented

2. Secure

3. Functional

Documentation

All the work that goes into building APIs will be useless if there is no proper documentation on how the service or an API works. This documentation includes a quick start guide, authentication information, API request types, sample code for popular programming languages, Tutorials, SDK examples (if available).

Documentation may be static and interactive. The latter allows for trying out APIs and see return results and usually consists of two columns: human and machine. The human column contains API descriptions, and the machine one has a console to make calls and contains info that clients and servers will be interested in when testing the API.

Mode of Authentication

Publicly available APIs usually have some form of Authentication or Authorization. In most cases, Authenticated requests are differentiated from regular requests via special Http header(s) or cookies. These headers or cookies are mostly identifiers that are tied to a particular customer. For example:-A company “A” wants to use the API of another company “B”. Company B then goes ahead to create an identifier for company A. The possible ways company A can choose to implement this “identifier” varies as different technologies exist for solving such problems like HMAC, JWT, uuid each with its own different way of implementation.

HTTPS

It’s the transport protocol (how data is transferred over the internet) with an extra layer of security (SSL). This layer makes data transferred encrypted in a way that only the client and server can understand.

URL

Stands for a Uniform Resource Locator. It refers to a unique address that is used to locate resources over the internet. Resources could be images, https etc. In this context, URL is the address for the API server and would mostly be called “endpoint”.

API Request Types

We use HTTP verbs, to perform CRUD operations e.g create, read, update, and delete.

GET request

An HTTP method that’s principally used for fetching data. Data can be added to GET request parameters

POST request

An HTTP method that’s principally used for sending data to the server. For POST requests, a “request body” is required.

PUT OR PATCH request

An HTTP method that’s used for updating data on the server. For PUT requests a “request body” is required. N.B: - this request completely replaces the resource.

DELETE request

An HTTP method that’s principally used for deleting data on the server.

For every request, there is a response and in API calls there are various types of response formats. We will be looking at the JSON (JavaScript Object Notation) response structure which is supported by Rest APIs. REST is the most popular however there are others like SOAP.

REST is considered a simpler alternative to SOAP, which many developers find difficult to use because it requires writing a lot of code to complete every task and following the XML structure for every message sent. REST follows another logic since it makes data available as resources. A unique URL represents each resource, and one can request this resource by providing its URL.

Web APIs that comply with REST architectural constraints are called RESTful APIs. These APIs use HTTP requests (AKA methods or verbs) to work with resources: GET, PUT, HEAD, POST, PATCH, CONNECT, TRACE, OPTIONS and DELETE.

RESTful systems support messaging in different formats, such as plain text, HTML, YAML, XML, and JSON, while SOAP only allows XML. The ability to support multiple formats for storing and exchanging data is one of the reasons REST is a prevailing choice for building public APIs these days.

JavaScript Object Notation (JSON) is a lightweight and easy-to-parse text format for data exchange. Each JSON file contains collections of name or value pairs and ordered lists of values.

Since these are universal data structures, the format can be used with any programming language.

A simple Get request and response sample below:

Base URL

This refers to the URL from which other endpoints on an API can be derived from.

Base URL This refers to the URL from which other endpoints on an API can be derived from. E.g. Considering the url “https:="" findme.com<="" a>="" 10001"="">https://findme.com/10001”, the base url is “https://findme.com” as other endpoints like “https://findme.com/user/profile”, “https://findme.com/all” can be derived from it. For the endpoints, described “/user/profile” and “/all” are said to be paths.

HTTP Status codes

These are standard numbers that are generally used to know the nature of the response returned from the server. E.g A response returned from an API with status “400” means that the data sent to the server was bad i.e “Bad Request”, “200" means request sent was ok i.e “ OK” See more http codes here.

For businesses who aim to grow, or to 10x your revenue, the most notable path from this article is collaboration, some services would take months or years to build however there are companies who have these today. The onus is on business owners, developers, product managers to think outside the box around various services and confirm that their business licenses are in order to resell those services (if yes, go ahead to request APIs from said company).

Bottomline

For every partnership, within the Fintech space or between two software companies, there are various APIs calls behind the scenes delivering the user experience the end-user consumes and also comes to love. A perfect example is watching YouTube videos on your Twitter timeline or paying your cable tv bills on bank applications or even accessing this post from various platforms. To improve our way of life, we need to build software that makes living easier and collaborate when or where there are opportunities to foster business growth.