What is an API and why are APIs indispensable in our digital world?

Just as people need a common language to communicate, computer systems need APIs, Application Programming Interfaces, for their interactions. An API is the standard way in which different software applications or platforms communicate and exchange information. In a world where digital connections are critical, APIs enable systems to add new features quickly and integrate with other systems seamlessly. This is essential for creating flexible, efficient, and innovative digital solutions.

Which types of APIs exist and what makes them unique?

There are different types of APIs, including REST, SOAP, RPC, and GraphQL. REST APIs, popular for web applications, use standard HTTP methods and are stateless. SOAP APIs, often used in enterprise environments, are protocol-based and provide advanced security options. RPC APIs focus on fast, direct function calls within a system. GraphQL APIs offer extensive query capabilities and are efficient at retrieving combined data from multiple sources.

How does an API contribute to secure data exchange?

APIs support secure data exchange through authentication, authorization, and encryption protocols. They ensure that only authorized users can access functions and data, and that data transfers occur securely. Modern APIs often follow the zero-trust principle, treating every request as potentially unsafe until proven otherwise. This minimizes the risk of unauthorized access and data breaches.

Application Programming Interface (API)

API stands for Application Programming Interface. An API is a standard connector between computer systems that allows them to exchange data and work together easily. Just as people need to speak the same language to understand each other, an API ensures that basic communication between computer systems is properly arranged. Thanks to APIs, we can quickly add new features to systems and connect new systems.

In this 'API for dummies', we first address the question 'what is an API integration?' and provide more detail on how APIs are structured and used. We then give examples of how APIs support digitization across different industries. We also describe the different types of APIs and their characteristics. Finally, we explain the benefits of APIs and show how they are used to connect our HelloID platform to various source and target systems used by customers.

What is an API?

Today, we handle more and more things online. Through your smartphone or laptop, you have one-click access to the news, can check your social media, or even book a flight. If we stay with that last example, such a travel app or website cannot function on its own. Through such an app, you specify where you want to go, how many people will travel, and when. The app then needs to access different airlines to find suitable flights and present them to the customer.

Today, there are countless airlines and travel applications. The last thing we want is to write lengthy specifications for every individual connection between an airline and a travel app. That is why APIs have been developed that allow travel applications to request information from such reservation systems in an agreed way. Similarly, sites like Booking.com offer APIs that allow individual home rental providers to list on their platforms. Another example is health insurers that use APIs to onboard healthcare providers easily. Banks use APIs to allow customers to link their personal accounts to their online accounting packages. APIs are the standard interfaces that let us quickly, securely, and reliably connect computer systems and make them work together in today's online world. But how does an API actually work?

How does an API Work in Practice?

First, an API integration requires agreements on several technical and practical matters to enable communication between systems. For example, we agree to send all information over the internet using the HTTP protocol. We also choose a specific data format, such as XML or JSON. There are several standard API styles, such as the REST API, where these general agreements have already been defined. You do not need to spend much time on these choices when designing an API; it is mainly a matter of selecting the right option. Later in this blog, we will explain several of these technical API styles in more detail, including REST, SOAP, RPC, and GraphQL APIs.

What makes each API unique is the data and instructions that systems can exchange through it. That also includes agreements about what the receiving system will do with that data. In effect, you can use an API to instruct another system remotely. Hence, the term Application Programming Interface: You can treat an application as something you can remotely program using instructions that you send through an interface to that system.

You can best compare an API to the server in a restaurant. You place an order for a bowl of soup with the waiter. The waiter walks to the kitchen and passes the order to the chef. You do not have to go to the chef yourself, nor do you need to explain how to make soup.

How does that work for the connection between the reservation system and the travel app? First, they can agree to use a REST API. Over that API, the following items can be exchanged, for example:

The travel app sends the trip details (destination, date, number of children/adults) to multiple reservation systems via the API.
The systems search for relevant flights based on the received data, checks availability and prices, and returns these details.
The travel app presents all available flights to the customer.
Once the customer selects a flight, the travel app sends a booking request to the relevant reservation system.
The system processes that request and books the flight.
The reservation system sends a confirmation and provides payment instructions. And so on.

With this API, we know how the travel app and the reservation systems work together technically. The advantage is that airlines can use the same API to receive new connection requests from other travel apps. All the details have already been specified in the API, and it is almost plug-and-play.

Example of an API

Similar to the example above in aviation, you will find countless APIs across every sector. Sometimes they are APIs used across an entire industry to integrate applications. There are also more universal APIs that are used much more broadly. If you want to use Google Maps on a website or in an application, you can do so with the established Google API. Below, we provide a few examples of APIs used in different sectors.

APIs in Healthcare

Healthcare is digitizing rapidly. Healthcare organizations use numerous systems, ranging from standard office automation to specialized care applications and medical systems. These are often off-the-shelf software products used across multiple organizations that must be able to integrate with other systems in various ways. Nedap Ons is an example. Nedap Ons is a comprehensive software solution that streamlines administrative tasks in healthcare organizations. It includes features for managing information about both employees and clients, planning, and authorization. To integrate Ons with other systems, Nedap offers a REST API that provides access to services and data on the Nedap Ons platform.

APIs for Government

Municipalities are complex organizations with numerous systems. Much of the work involves long-running cases, such as permit applications, subsidy requests, or passport renewals. These cases are managed in a so-called case management system where all relevant data about a case is stored. A case management system requires many interfaces. For example, the Customer Contact Center allows staff to answer citizen questions quickly and accurately. Other municipal IT systems also query information from such a case system. That is why it is now required that case systems use the so-called 'APIs for Case-Oriented Working.' Municipalities no longer need to copy data between systems; data can always be consulted directly in the source system. This is an example of a government API designed to accelerate municipal digitization.

APIs for the Commercial Market

Human Resources is taking on an increasingly important role in companies. It used to be primarily the administrative personnel department. Today, the focus is much more on recruiting and retaining talent. In more and more processes, from payroll to user account issuance, the HR system serves as the authoritative source. Modern HR systems, such as AFAS and Visma, therefore provide APIs to expose HR data to other systems. Visma Raet, for example, targets government agencies, healthcare, and educational institutions. The system offers the Visma.net HRM & Payroll API, among others, for integrations with in-house developed systems and third-party applications.

The Difference Between APIs and Web Services

Sometimes the terms API and web services are used interchangeably. It is useful to clarify that term as well. A web service makes applications accessible to external systems over the Internet. For example, an online store does not need to build its own payment functionality. It can simply integrate with a payment provider that handles payments by using a web service.

A web service, therefore, functions as an API between the payment provider and the connected online stores. However, it is a very specific type of API. A web service is intended solely for communication over the internet; its use is defined in the Web Service Description Language (WSDL), and it always uses standards such as SOAP, HTTP, and XML.

So a web service is one of the various types of APIs used today. Many APIs work differently. They may use other network types, standards, or data formats. In fact, some APIs do not use a network at all and are used to connect systems directly. Finally, APIs enable different applications within a single system to work together. For example, an operating system like Windows includes numerous APIs that let applications, peripherals, and more interoperate on your computer. A web service is an API, but not every API is a web service.

Different Types of APIs and Benefits

What is a REST (JSON, XML, HTML) API?

REST stands for Representational State Transfer. The REST API, or RESTful API, was developed in 2000 and is popular for its flexibility. Information can be sent over different protocols; in web environments, the HTTP protocol is usually used, so no additional API software is required. Standard HTTP methods such as GET, POST, PUT, and DELETE can be used, and because short messages are used, REST APIs are relatively fast. A REST API is also stateless; no session information is stored, so each request to a system must include all necessary information.

REST APIs support different data formats. JavaScript Object Notation (JSON) is popular in web environments for its relatively light, simple structure. The more structured, eXtensible Markup Language (XML) format is mainly used for more complex data. Lastly, HyperText Markup Language (HTML) is the markup language for web pages, and is also an option. REST APIs are ideal for lightweight APIs and are used by many online services, from X to Spotify.

What is a SOAP (XML) API?

Simple Object Access Protocol, SOAP, is a veteran among protocols; SOAP has existed for 25 years. SOAP APIs are primarily used for web services and use the HTTP protocol. There are also legacy SOAP integrations that use the Simple Mail Transfer Protocol (SMTP) to transport information.

SOAP uses XML. As outlined above, this is a more structured information format, which makes messages larger and slows data exchange. SOAP is somewhat heavy for simple web applications, but it is well-suited for supporting complex data exchange and processes in enterprise environments. SOAP also provides more advanced security measures. Given these characteristics, SOAP is widely used, for example, in payment services and in communication between banks and other large enterprise environments.

What is an RPC (TCP, UDP) API?

RPC stands for Remote Procedure Call. This approach has been in place for quite some time, and you can debate whether it is truly an API. Earlier, we compared an API to the waiter in a restaurant, a middleman. Extending that comparison, RPC is more like a restaurant guest who shouts directly to the chef that he wants soup. With RPC, an application can directly invoke functions within the receiving system. That has advantages; it is direct, fast, and powerful, but the communication is not secured by default and is not very flexible. If you want the system to do something different, you must adjust the interface again. Communication occurs over the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP).

What is a GraphQL (HTTP) API?

GraphQL was developed by Facebook and is interesting for its extensive filtering capabilities and the ability to send commands to multiple systems at once. As a result, you can specify exactly which information you are looking for in a query to the system, and only that data is returned. The complexity of multiple linked systems is abstracted away, and you receive the coherent results of your query.

Overview Table

	REST API	SOAP API	RPC API	GraphQL API
General	Based on standard HTTP methods, GET, POST, PUT, and so on.	Uses XML, normally over HTTP	Simple procedure calls via direct function invocations	Query language for distributed systems
Data formats	JSON, XML, or HTML. Other options possible	XML	XML, JSON. Other options possible	Often JSON, but can support other formats
Protocols	Normally, HTTP protocols; other options are possible	Can use various protocols, such as HTTP, SMTP, and others.	Usually TCP or UDP	Uses HTTP; the underlying protocol may vary
Stateful or stateless	Always stateless	Stateless and stateful	Stateless and stateful	Normally stateless, but can be stateful
Flexibility	More flexibility in endpoint URLs and data formats	Less flexible, requires explicit definition of data structures and actions	Less flexible, because methods are invoked directly	Provides a high degree of flexibility and lets the client specify the required data
Speed	Generally faster due to less overhead	May have more overhead, which can make it slower	Can be fast due to direct calls to the target application	Efficient because only the required data is retrieved
Security	Supported, but pay attention to the implementation of authentication and authorization.	Can provide complex security options, for example, WS-Security	Requires additional security measures	Provides field-level security

Benefits of Using an API

APIs make it easy to combine functions from different systems to create new solutions. You reuse as many existing applications and functions as possible so you can focus on what is new. In the travel app example, the owner can focus entirely on developing the app while relying on existing functionality and standard API integrations for flight data from reservation systems. This allows you to concentrate on what you truly want to develop anew, while the implementation of the overall solution remains manageable, secure, and flexible. We explain this in more detail below.

Sense of Control

Digital innovation depends on the ability to make different systems work together easily. This allows you to reuse existing functionality without issues or to query data from other systems with minimal effort. At the same time, this must be done in a controlled way. If we start creating ad hoc connections between all kinds of systems and plug directly into each other's software and data, we will end up in no time with a spaghetti architecture; an architecture where the slightest change causes functionality, reliability, or security to start failing.

A sound architecture with well-developed and well-documented APIs gives systems controlled access to each other's functionality and data. The system owner remains in control of how those elements are used, and other systems never have direct access to the code. System changes also pose no problem. Existing functions and data remain accessible through existing APIs, while new functionality can be made available as needed through an API update. The system as a whole remains under control.

API Security

Modern APIs must be an integral part of your information security. Before we collectively moved to remote and hybrid work, corporate networks were often secured like a castle. At a castle, the walls and the gate constitute the security, but behind them, there is little left to stop intruders. Similarly, IT managers focused entirely on access control to their corporate network. Once inside that network, there was little control over user behavior, and the connections between systems were often simply left fully open. Now that we all work remotely and in the cloud, this traditional perimeter security model is no longer tenable.

Zero-Trust Principle

IT applications can be accessed remotely by users, and systems also communicate over the internet with systems outside the organization. Modern IT networks must therefore be based on the zero-trust principle, in which we never blindly trust anything or anyone. For every user session and for data exchange between systems, the questions are: who is requesting access, what that party's role is, and which access rights the system has. Modern web APIs make this possible. The following explains how to securely apply an API.

Flexibility

Organizations as a whole must respond ever faster to new societal developments, market trends, and technological innovations. IT must also be more agile. Applications must be easy to connect to or decommission. Modern APIs support this. Integrating systems rarely requires a lengthy system integration project anymore; an API can usually be configured and activated quickly.

Modern HR systems are an example. They are connected to other enterprise systems through APIs. Often, a new HR package is selected after a few years. If a different package is chosen, a migration can be executed quickly thanks to the available APIs. You can not only connect the new application quickly via APIs, but also transfer data to the new system efficiently via APIs.

How Do You Deploy an API Securely?

As explained above, modern APIs must operate under the zero-trust principle. We must never assume blindly that an interface between two systems is trustworthy. Just as users must authenticate who they are when requesting access to another application, applications must authenticate who they are when requesting access to another application. A connected system must also have the correct authorization, what someone is allowed to do, to issue commands to that other system. It is increasingly important to grant people and systems access only to the functions and data that are truly necessary. This is especially important because more and more personal data is being sent between systems.

The GDPR imposes strict rules on this. Systems may process personal data only for clear and legitimate purposes. This is called purpose limitation, and in a good API, you can configure data selection so that only the data required by the receiving application is shared. For example, if you connect an HR system to a learning tool, that system does not need absence data. Those data must therefore be blocked for that application.

Tip: Test your API
For authorization the OAuth 2.0 standard is often used. Because attention naturally focuses on authentication and authorization of human users, it is extra important to test the security of APIs as well.

Efficient API Integrations for Identity and Access Management

How do we use APIs within an Identity and Access Management (IAM) platform, and which IAM APIs exist? We explain this using our cloud-based HelloID platform. As an IAM platform, we integrate with so-called source systems and target systems.

Source Systems are usually HR systems, such as AFAS and Visma Raet. They feed the IAM platform with information about new employees, job changes, and departing employees. Based on this information, we create new accounts, manage access rights, and eventually deprovision accounts.
Target Systems are the systems to which we send information. When a user account has been registered in HelloID and the associated access rights have been determined, we also create the accounts in Active Directory or Entra ID. We also send account details and settings to business applications, such as Nedap Ons, a widely used healthcare system, and to service management systems, such as TOPdesk.

Incidentally, many source systems, such as AFAS, are also target systems. For new employees, HelloID creates a self-service account on the HR system to manage personal information and view pay stubs.

200 Software Connectors

IAM therefore acts as the hub between all systems. To connect systems, we now offer more than 200 connectors to existing systems. A fundamental aspect of these connectors is their ability to integrate with a wide range of APIs, each with its own specific characteristics and formats. As explained earlier in the article, the nature of these APIs varies considerably; some systems use REST, others SOAP, or GraphQL. In addition, the way data is exchanged and the requirements for requesting data can vary greatly across APIs. For example, one HR system may provide all personnel data directly. At the same time, another may require you to first request a list of all employees, then make individual data requests or API calls for each employee.

The primary function of a connector within this complex landscape is to standardize these diverse data flows. Regardless of the diversity of APIs and the formats in which they deliver data, the connector transforms them into a uniform format. This ensures that data exchange across different systems is consistent and streamlined. In addition to converting data, a connector can also include additional logic and controls that contribute to an efficient and reliable integration. Through the connectors, HelloID can read person and contract data and configure accounts and access rights. Our approach with HelloID provides maximum flexibility and normally eliminates the need to modify connected systems. The connector, therefore, serves as a bridge between the diversity of APIs and the standardized requirements of our IAM platform.

Handling API Changes

If a vendor of a connected system changes something in their API, we modify the connector. This can also be necessary if a system API gains more capabilities. For some target systems, HelloID can currently create or remove only a basic account due to API limitations. Specific access rights must then still be managed through the system itself, for example, in a healthcare system where you must configure within the system who is allowed to access which patient data. As soon as the vendor expands this API, we can adjust our connector and manage these detailed settings in HelloID as well.

View all supported source and target systems

All connectors