What Is an API Call?

An application programming interface, better known as an API, is essentially a set of rules and protocols that allow software programs to communicate with each other. APIs are especially useful when writing programs that need to access data from another program, such as a mobile app that needs access to the data stored by a database or web app. With that in mind, when an API request is made by one program to another to access its functionality or data, it’s referred to as an API call.

When a client makes an API call, the destination of that request is an API endpoint. API endpoints are a way to access the data or functionality of an application, service, or software. It’s a specific URL that can be used to access data from an external source, such as a database or web service. It can also be used to create and manage data on the fly, such as in a web application.

When the API endpoint communicates back, it’s known as a response. It’s important to know that responses can vary. Oftentimes, the response is the data that the client requested in the API call. If the API is unable to verify API clients, responses can also return error codes.

The most common types of APIs are REST APIs, which use HTTP-based API call methods. The most common methods are GET, POST, PUT, DELETE, and batch. We’ll cover those below. But keep in mind that there are other types of APIs, including SOAP, GraphQL, XML, and more.

These are normally used for retrieving records to the calling application from an access point provided by the API provider. The calls retrieve or update/create a record and return a status code, along with a response header and body that contains the payload. GET/POST calls can be used to get data from the internet and/or change what is displayed on a website; for example, you may have a messaging app that lets you search for a friend’s location based on the city they live in and then click on the friend’s profile picture to see where they are located on a map. In this case, the GET call would be used for searching for that friend, and the API would return their city name and the country they are located in in the response payload. GET calls can also be used by applications to do things like check your account balance, pay bills online, or get updates on the weather in your local area.

These methods are used for updating or deleting records using the API. The request must contain the appropriate HTTP headers (usually authentication, at a minimum) as well as the body of the request that contains the necessary information for the update or deletion to occur. Similar to GET/POST calls, these also return a status code and potentially a body with the response payload. PUT/DELETE calls are also sometimes called “application-to-application” (A2A) or “self-service” calls because they allow one application to communicate with another. For example, say you are using the Pinterest app on your phone and you want to create a board for your favorite recipes. Clicking to create the board would cause your Pinterest mobile app to make a PUT call to POST the board to Pinterest’s API. Or perhaps are watching a video on YouTube and you tap the screen to pause the video. The platform might send a GET call to check your channel subscriptions to see what other videos you might like to watch next.

These are used to submit multiple requests to an API endpoint at once. Each batch must consist of a valid header as well as an array of body data. Batches may be repeated several times to gather more data over a period of time. Batch calls are great for issuing multiple requests in one go. They are useful for things like uploading large volumes of data or taking many actions in a short period of time. For instance, a developer might set up an automated job that runs every hour to fetch new content from a website or add new products to an online store using a batch call. If you want to issue multiple requests at once, a batch call, which is similar to the GET/POST calls mentioned previously, is most efficient.

When making API calls, it’s important to understand how APIs handle data through headers like “content-type.” This header informs the server and client about the format of the data being sent or received, such as JSON, XML, or plain text. Correctly setting and interpreting content types ensures that the API request and response are properly understood by both parties.

For instance, a GET request from a client might expect the server to return data in JSON format, with the API response including a “Content-Type: application/json” header. If the server does not send the data in the expected format, it can lead to errors or incorrect data interpretation. Developers must handle content-type specifications carefully to ensure smooth communication between systems.

Properly specifying content types also adds another layer of API security, preventing data from being interpreted in unintended ways, reducing the risk of potential vulnerabilities like injection attacks.

An API call is considered safe if it is made with the correct credentials and if it’s not being used for malicious purposes. However, API calls can lead to an attack if they are not properly secured. This is because the API call is made from a different domain than the one from which it is being called. This means that if an attacker manages to get access to your API call, they will have access to your entire system and all of its data.

There are many ways that API calls can be used for malicious purposes, such as:

• Sending spam emails or phishing attacks
• Hijacking a user’s session and stealing their personal information
• Using a botnet to send out spam or DDoS attacks

Protecting API calls can be tricky because a lot of popular websites and apps have millions of users accessing them simultaneously, so it’s easy to get confused about where requests are coming from. Furthermore, there are so many new threats created every day that it’s tough to keep up with them all. However, there are a few things you can do to make sure your API calls are safe and secure.

Keep an accurate API inventory

Developers will use APIs to cross connect microservices and applications in order to exchange data. The first thing an organization can do to make this process more secure is have an accurate inventory of the APIs available to the development teams. Oftentimes a duplicate API will be created because the existing one is unknown to the development team. This unnecessarily increases the number of attack vectors for an organization.

Test APIs for vulnerabilities

Another common cybersecurity threat is excessive data exposure, where developers keep adding new data types to a single API, in an attempt to reuse existing tooling. The risk here is that all data types for a given record may be exposed by the API, even if they are not needed for by the requesting client. This data could be harvested by an attacker. Finally, business logic should be built into the API code to make sure it cannot be abused. Your API security testing solution should be able to test and uncover any flaws with your business logic.

Securing API calls with API keys and access tokens

API keys and access tokens are critical in managing and securing API calls, ensuring that only authorized clients can access API endpoints. API keys serve as unique identifiers, allowing API providers to track and authenticate client requests. When an application or user sends a request to a web API, the API key is included in the header or query string, identifying the sender.

Access tokens, often used in OAuth-based APIs, provide a more secure alternative by granting temporary access to specific resources. These tokens are typically issued after the user is authenticated, allowing them to interact with the API for a limited period. Ensuring API keys and access tokens are handled securely is crucial, as their exposure could lead to unauthorized access or API abuse.

API management platforms offer additional layers of security by allowing developers to implement rate limiting, quotas, and IP allowlisting, protecting against overuse and malicious requests.