What is an API (application programming interface)?

APIs expose only the data and functionality needed for a specific interaction, keeping other internal implementation details hidden. This abstraction protects system integrity and simplifies how software components communicate.

There are many kinds of APIs—hardware and firmware APIs, operating system APIs, library and framework APIs, web APIs and more—and at a high level, they all operate in the same way: they define a contract between two pieces of software, specifying what can be requested and returned.

As an integration-centered explainer, this article predominantly focuses on web APIs (a type of API that enables software to make requests over a network, often using HTTP), how they work, their differences and how they are used to connect systems, synchronize data and automate workflows.

It’s useful to think about API communication in terms of a request and response between a client and server. The application submitting the request is the client, and the server provides the response. The API defines the terms of communication between them.

For a simple example, consider third-party payment processing. When a user purchases a product on an e-commerce site, the site might provide the option to “Pay with PayPal.” This function relies on APIs for this connection.

• When the buyer clicks the payment button, an API call is initiated. This request is processed from an application to the web server through the API’s uniform resource identifier (URI) and includes a request verb, headers and sometimes, a request body. Together, these specify what is being requested, and how.
  
  
• After receiving a valid request from the client, the API forwards the request to the external program or web server, in this case, the third-party payment system, and returns a response with the requested information.
  
  
• The API transfers the data to the initial requesting application, in this case, the product website.

To the end user, this entire exchange is invisible—they simply see a successful payment confirmation.

APIs exist at every layer of software, from close to the hardware up to the web services that most people interact with daily. In many everyday conversations, API is used synonymously with web API. But there are many types of APIs serving different use cases, including:

• Hardware and firmware APIs enable software to communicate with the physical components of a device such as processors and sensors.
  
  
• Operating system APIs enable software to communicate with operating systems for services like file, process and memory management.
  
  
• Library and framework APIs expose prewritten code—functions, methods and hooks—that developers interact with directly within their applications without going over a network. 
  
  
• Database APIs enable software to communicate with, manipulate and extract information stored in a database.
  
  
• Web APIs enable software to make requests over a network, often using HTTP. They are a type of remote API, facilitating communication and resource manipulation between different machines, rather than a single device.

*It’s worth noting that some older systems expose network protocols—such as FTP, SMTP and SSH—directly as their integration interface. Technically, these fit a broad definition of API, though they are categorized by how they communicate, rather than what they interface with, and are less germane to an integration-focused discussion.

Web APIs are the most common for integration. Unlike the other API types listed above, they are designed for communication between separate applications over a network.

REST is the dominant architectural style for web APIs today. REST APIs, also known as RESTful APIs, rely on six guiding architectural constraints first defined by Roy Fielding for the creation of scalable, flexible and decoupled web services.

REST makes data available as resources, and REST APIs use HTTP methods such as GET, POST, PUT, PATCH and DELETE to interact with these resources. Each resource is identified by a unique URI, commonly referred to as an API endpoint. This is the specific address that the client sends an API request to.

REST is defined by the following constraints:

• Uniform interface - Creates standardized communication rules: all requests for the same resource should look the same. Each resource should have one URI.
  
  
• Client/server separation - Client and server applications must be able to evolve separately, without any dependencies. The only information that the client has is the resource URI.
  
  
• Statelessness - The server does not store session state between requests. Each request is self-contained and must include all necessary information to process it.
  
  
• Cacheability - All resources should be cacheable when possible, and the server must declare these resources cacheable.
  
  
• Layered system architecture: Because each request in REST is self-contained, the client doesn’t need to know whether it is communicating with the origin server or an intermediary. This makes REST well suited for public APIs serving many clients.
  
  
• Code on demand (optional): REST APIs usually return data. This final constraint (the only optional constraint) permits the return of executable code, such as JavaScript, that the client can run when needed.

For a more complete explanation of the REST principles, go here.

SOAP is an XML-based messaging protocol with strict standards for how messaged are structured and transmitted. Unlike REST APIs, which in practice run almost exclusively over HTTP, SOAP is transport-agnostic. It can operate over HTTP, SMTP and other protocols, making it more flexible in enterprise environments where HTTP is not always the underlying protocol.

SOAP messages have a rigid structure that specifies how the message should be processed, making SOAP more verbose than REST, but also more standardized. SOAP’s formal standards, built-in error handling and rigid security specifications remain valuable and drive its continued use today in industries like finance and healthcare.

RPC predates web APIs and has both legacy and modern implementations. RPC, sometimes called a subroutine call or function call, enables an application to execute a function or method on a remote server as if it were local. RPC is organized around actions instead of resources. Rather than individual URIs for each resource, RPC APIs typically expose a single endpoint and specify the action within the request payload.

The direct predecessor to JSON-RPC, XML-RPC uses XML to encode its calls and responses. It is older than SOAP but simpler, making it easier to implement—though XML’s verbosity makes it heavier than JSON-based alternatives. It is essentially a direct ancestor of JSON-RPC.

JSON-RPC works the same way as XML-RPC but uses JSON instead of XML. JSON is more compact and easier to parse than XML, making JSON-RPC lighter and more readable than its predecessor.

gRPC is the modern, high-performance tier in the RPC family. It was initially developed by Google and is now maintained as an open source project. Where older RPC implementations use text-based formats, gRPC uses Protocol Buffers (or Profobuf), a binary serialization format that produces smaller, faster messages than JSON or XML.

It also runs over HTTP/2 rather than HTTP/1.1, adding further performance benefits. gRPC is commonly used for internal microservice communication and supports bidirectional streaming, making it a strong choice for real-time data flows.

GraphQL is an open source query language and server-side runtime developed by Facebook in 2012 to facilitate more efficient resource fetching. It is designed to eliminate overfetching (receiving more data than needed) and underfetching (requiring multiple requests to receive data needed) by enabling clients to specify exactly what data they want. GraphQL uses a single endpoint through which clients can query multiple resources, with the results returned in a single response.

Though highly flexible, GraphQL is more complicated than REST, and is most used in complex environments where client data requirements vary significantly.

Read a more in-depth comparison of REST vs. GraphQL here.

The aforementioned APIs all follow a request/response model initiated by the client. Two important exceptions are worth noting in an integration context:

• WebSockets (WebSocket APIs) maintain a persistent, bidirectional connection, suited for real-time use cases like live data feeds.
  
  
• Webhooks invert the model entirely—rather than the client initiating a request, the server pushes notifications to the client when a specified event occurs.

Public APIs are fully exposed to the internet and are available to any developer or organization, generally with no, or minimal, restrictions. Developers might be required to obtain an API key, but otherwise, there’s not much required to work with these APIs. They are designed to encourage external integration and third-party development.

*Not to be confused with the “OpenAPI Specification (OAS),” which you can learn more about here. 

Private APIs are not available to the public and are only accessible within a defined organization. They are often isolated on private networks and require strict authentication for access. Organizations commonly use such APIs to connect internal software systems.

From an access perspective, partner APIs sit in between public and private APIs in that they are available to a specific group of authorized business partners. Though they might be reached over the public internet, they are not available to the public, and access is granted only to authorized users. Partner APIs are used for things like B2B data sharing or to monetize data streams, and their use is often governed by specific partner agreements. 

*Composite APIs are sometimes included in this access-type breakdown but are better understood as an architectural pattern than an access level. Composite APIs combine API calls, and they can be public, private or partner. They are discussed further in the APIs and microservices section.

API design is the decision-making process that determines how an API exposes data and functionality. In the design process, teams decide what protocols and architectural styles the API will use, establish consistent conventions for naming, response structures and error handling, decide how access will be authenticated and authorized, and define a versioning strategy for managing breaking changes. These and many other decisions shape how an API works and how developers interact with it.

Essentially, it’s a process that starts with questions like, “How will this API be used?” and moves forth to develop a design blueprint for APIs that satisfies the organization’s needs.

An organization’s API governance policies often shape API design. API governance refers to the comprehensive set of standards, policies and practices that direct how an organization develops, deploys and uses its APIs. Effective API design produces APIs that adhere to these predetermined policies.

API documentation is like a technical instruction manual that provides information about an API, such as supported protocols, languages and authentication methods, code snippets, structural definitions and other information necessary for developers to work with an API. Comprehensive, up-to-date API documentation promotes a better API experience for developers and drives successful API adoption, integration and management.

API-first (or API-design first) is a software development approach in which APIs are treated as the foundation of an application, designed before any application code is written. Rather than start with the backend business logic and database structure, organizations define the contract first—often using an API specification like OpenAPI—and build the rest of the application around it.

It’s a preferred approach for integration-heavy organizations, favored for its scalability, reliability and consistency: the API is the source of truth, and all consumers—web and mobile apps, Internet of Things (IoT) devices, AI apps and models, and other systems—interact with the same API layer rather than bespoke integrations.

Some organization’s treat API-design first and API first as distinct approaches, the latter being a broader, organization-wide function that treats APIs as products themselves, with their own lifecycles, product managers and roadmaps.

Microservices is an architectural style that divides an application into smaller, independent services. These services communicate through APIs, often a mix of protocols and styles: for example, REST APIs for external-facing services, gRPC for internal inter-service communication and webhooks for event-driven flows. A microservices architecture gives developers the flexibility to choose the framework that works best for a particular service.

It also enables developers to test, deploy, update, integrate, maintain and scale services independent of one another. Fault isolation is simplified—a single component failure doesn’t crash the entire application—and because services are loosely coupled, internal implementation can change with breaking integrations.

One common microservices issue is what’s known as the “chatty front end” problem. In a traditional application, data lives in one database and a client can query this database with a single call. In microservices, data is spread across many services, which can require a client to communicate with dozens of services, through dozens of separate requests, to get the data it needs. Composite APIs solve this problem by presenting a unified endpoint that serves as an orchestration layer, fielding a client request, communicating with various backend services to gather the requested data, and returning it to the client in a single payload.

Composite APIs eliminate the need for clients to make multiple round-trip calls for a single operation. They also hide internal system complexity: the client doesn’t need to know which microservice handles which data, only how to reach the composite endpoint. And they can reduce latency, since a single call relying on internal microservice communication is typically faster than several round-trip calls over an external network.

For all their benefits, microservices architectures expand the API surface and add complexity, highlighting the importance of strong API management.

API management is the process of publishing, securing, controlling and monitoring APIs over their lifecycle. This work is typically centralized through an API management platform that helps organizations enforce consistent policies across all their APIs. Many of these platforms also include design and documentation tools, though this section focuses on management’s operational role.

API management includes the oversight of:

An API gateway is a software layer that presents a single entry point for clients to access multiple backend services. They prevent clients from having to understand or interact with the architecture complexity behind the gateway and are used to tame the proliferation of APIs created by microservices.

Key functions include routing, authentication, rate limiting and monitoring. Gateways can also handle request aggregation, which makes them a common place to implement composite APIs.

API security is a set of practices and procedures that protect APIs and the data they transmit from misuse, malicious bot attacks and other cybersecurity threats.  API security includes authentication (verifying a user’s identity), authorization (determining what they’re allowed to do), encryption, input validation and more. Common security technologies include API keys and OpenID Connect (ODIC) for authentication and OAuth for authorization. A strong API security posture helps ensure that only authorized users and applications access APIs. 

Rate limiting and throttling control the volume and flow of API requests to help keep systems stable and available. Rate limiting restricts the number of calls an individual client can make in a specified period, and throttling manages the volume of calls a system accepts, generally by slowing or queuing requests. Rate limits also serve a commercial function, enabling organizations to enforce usage tiers for paid APIs.

While they are primarily operational concerns, both limiting and throttling serve a secondary security role, helping thwart denial-of-service and credential-stuffing attacks.

API management enforces the versioning strategy set out in design. Management platforms enable organizations to route traffic to the correct API version, run multiple versions concurrently and manage the deprecation of older versions. This lets teams roll out updates and new versions—even breaking changes—while providing time for existing integrations to migrate without interruption.

APIs are the connective tissue between enterprise systems, services and partners, and it’s vital to understand how they are working. A failing API can cause issues with every integration that depends on it; monitoring and observability help teams detect and diagnose such problems before they cascade across connected systems.

API monitoring tracks the performance, availability, functionality and usage of APIs, providing alerts when metrics such as latency or error rates cross predefined thresholds. Observability expands upon monitoring, using metrics, logs and traces to gain a deeper understanding of system health and surface information that monitoring doesn’t flag.

Understanding API usage helps teams plan capacity, address potential threats and adhere to governmental and regulatory requirements.

APIs connect software applications, systems and workflows for the exchange of data and services, a function often referred to as API integration. In most modern integrations, APIs are central to the movement of information between services and systems.

Common enterprise use cases include:

APIs enable teams to integrate third-party services into their applications and workflows. For example, if a hot sauce company wants to include a store locator map on its website showing partner retailers, it can use the API from a mapping application to embed that information on its site.

Organizations use APIs to share data and services with partners, suppliers and customers. A logistics company might use an API to expose order tracking information so that retailers can incorporate it into their own systems.

Organizations use APIs to facilitate data exchange between enterprise systems—such as customer relationship management (CRM) and enterprise resource planning (ERP) platforms. If a customer address is updated in a CRM platform, this change can be automatically propagated across connected systems.

APIs are used to access AI tools such as large language models (LLMs) and machine learning models, and to incorporate them into applications and workflows. Integrating AI models works like other third-party integrations: instead of a team having to build and train a complex model internally, they can use an API to access an external model.

AI agents also use APIs to access services and complete tasks, but they work differently than traditional integrations in which a developer decides in advance which APIs to call and how to call them. AI agents make this decision at runtime and must be free to analyze a problem, choose a tool and explore solutions on the fly. They need a consistent way to discover tools and understand how to use them.

Model Context Protocol (MCP), an open source standard introduced by Anthropic and now governed by the Linux Foundation, connects AI models and agents with external applications and systems, addressing this gap. MCP servers typically sit on top of existing APIs as a “universal translator,” describing the capabilities of a tool in a standardized way that any MCP-compatible AI application can use. Rather than building a custom integration between every AI application and every tool, developers can build one MCP server for a particular tool and make it available to any compatible agent. MCP is often compared to a USB-C port for AI applications, providing one standard connector instead of many custom ones.

Mobile and web applications use APIs to communicate with their backends and retrieve data or trigger actions without ever accessing databases or business logic directly. An organization can build the backend functionality once and use APIs to serve web, iOS and Android clients. New channels can be added without having to rebuild the backend.

Some organizations take this a step further with a backend-for-frontend approach that adds thin client-specific layers on top of shared APIs while keeping the core business logic in one place.

Some applications can’t wait for clients to request information. Real-time and event-driven APIs flip the relationship, pushing information as soon as it changes or when a particular event occurs, rather than waiting for clients to repeatedly request updates.

Webhooks notify connected systems upon specific events, while WebSockets and gRPC streaming maintain continuous connections for ongoing data flows. Together, they power financial trading platforms, chat systems, multiplayer gaming and IoT sensor data exchange, keeping systems current without the need for constant polling.