An application programming interface (API) is a defined way for one software application to request information or services from another. APIs allow applications to exchange data and use one another’s capabilities without needing to know how the other system works internally.
When you check the weather on your phone, sign in to a website using an existing account, or pay for an online purchase, APIs may help make those interactions possible. They provide a structured way for different software systems to work together, even when those systems were built by different developers, use different programming languages, or run on separate computers.
APIs are a fundamental part of modern software because few applications operate entirely on their own. Many depend on external services, databases, payment processors, maps, identity systems, and other applications. By defining how these systems can interact, APIs make it possible to combine their capabilities into a single user experience.
What an API does
The term API stands for application programming interface. Each part describes an aspect of its purpose: an application is a software program, programming refers to the instructions developers write, and an interface defines how one system interacts with another.
An API specifies the operations a software component makes available, the information needed to request those operations, and the form of the results. Depending on the API, it may also define how errors are reported, how access is authorized, and what limits apply to requests.
Consider a weather application that needs to display the temperature in a particular city. The weather data may be maintained by a separate service. Rather than collecting atmospheric measurements itself, the application can send a request to that service through an API. The service processes the request and returns relevant weather information in an agreed format. The application then displays the temperature and other details to the user.
The weather application does not need to know how the service gathers observations, combines measurements, or produces forecasts. It only needs to understand the API’s documented rules.
This separation between a system’s internal implementation and its externally available capabilities is one of the most important properties of an API. The service can change its internal software without necessarily affecting applications that use it, provided the API continues to behave as expected.
An API is not necessarily a separate application or a physical piece of equipment. It is an interface defined by rules and implemented by software. It can connect programs running on the same computer, components within a single application, or services communicating across the internet.
How applications communicate through an API
When one application uses an API provided by another system, the communication usually follows a defined sequence. The precise details depend on the API’s design, but network-based APIs commonly involve a client, a server, a request, and a response.
The client is the application or software component that initiates the interaction. The server is the system that receives the request and provides the requested information or performs the requested operation. These roles describe what the systems do in a particular interaction; a single system can act as a client in one situation and a server in another.
Suppose a travel website needs to display available hotel rooms. The interaction might unfold as follows:
- The website gathers the information needed for the search, such as the destination, travel dates, and number of guests.
- Its software sends a request to a hotel-booking service through the service’s API.
- The service checks the request, applies its rules, and retrieves or calculates the relevant availability information.
- The service returns a response indicating the results or explaining why the request could not be completed.
- The website interprets the response and presents the available options to the visitor.
The user sees a search result, but behind that screen, multiple software components may have exchanged information.
In a typical internet-based interaction, the request travels over a network using established communication protocols. A protocol is a set of rules governing how information is transmitted and interpreted. The receiving system uses the API’s definitions to understand what the client is asking for, while the client uses the response format to understand what the server sends back.
Not every API interaction requires an internet connection. An API may allow one component to call a function provided by another component within the same program or on the same computer. The common principle is the same: the systems communicate through a defined interface rather than relying on undocumented assumptions about each other’s internal workings.
How API requests and responses work
A network API request often contains several kinds of information. These may include the operation being requested, parameters that describe what the client needs, authentication credentials, and data that the server should process.
Many web APIs use HTTP, the protocol that underlies much of the web’s communication. A secure connection commonly uses HTTPS, which protects information in transit through encryption and helps authenticate the server.
HTTP requests include a method that indicates the general type of operation. Common methods include GET, POST, PUT, PATCH, and DELETE. Their intended uses differ, although the exact behavior of a particular API depends on its design.
GET is commonly used to retrieve information. A weather application might request the forecast for a specified location. POST is often used to submit data or initiate an operation, such as creating a new order. PUT commonly replaces a resource or sets it to a specified state, while PATCH applies a partial modification. DELETE is generally used to remove a resource.
These methods are conventions with defined HTTP semantics, not guarantees that every API implements every operation in the same way. A well-designed API documents what each method does and what effects a request may have.
Requests may also include headers, which carry metadata about the communication. A header can identify the expected response format, provide an authorization token, or specify other details needed to process the request. Some requests include a body containing structured data, such as the details of a new order. Other requests convey their parameters through the URL.
The server responds with a status code, headers, and, when appropriate, a response body. A status code indicates the general outcome of the request. For example, a successful response might use the code 200, while a request to create a resource might receive 201. A 400-level code generally indicates a problem with the request or access to the resource, and a 500-level code indicates that the server encountered an error.
The response body contains the information returned by the server, if any. A successful response may contain requested data, a confirmation that an operation was completed, or information about a newly created resource. An unsuccessful response may explain what went wrong.
These distinctions matter because receiving a response is not the same as receiving the desired result. A client must interpret both the content and the status of the response to determine what happened and how to proceed.
How APIs represent and exchange data
Applications often store and process information in different internal formats. One might represent a date as a specialized date object, while another uses a text string or a numerical timestamp. For communication to work reliably, both systems need an agreed way to represent the information being exchanged.
Many web APIs use JSON, short for JavaScript Object Notation. Despite its name, JSON is a language-independent data format used by applications written in many programming languages. It represents structured information using objects, arrays, strings, numbers, Boolean values, and null values.
A weather service might return information in a form like this:
JSON
{
"city": "Denver",
"temperature": 18,
"unit": "Celsius"
}The receiving application can interpret the fields according to the API’s documentation. It knows that the city field identifies a location, the temperature field contains a number, and the unit field specifies how to interpret that number.
JSON does not itself explain what the data means. That meaning comes from the API’s contract: the documented agreement describing the available operations, required inputs, expected outputs, and relevant constraints. Without that agreement, a client might misinterpret a number, assume a missing field is an error, or treat a measurement in the wrong unit.
APIs can use other formats, including XML and protocol-specific binary representations. The appropriate format depends on the system’s requirements, such as compatibility, data complexity, performance, and the need to communicate with existing software.
A well-defined data format makes information easier to exchange, but it does not eliminate every compatibility problem. Two applications may use the same format while disagreeing about field names, units, time zones, optional values, or the meaning of a particular status. Reliable integration therefore requires agreement on both the structure of the data and its interpretation.
What happens when an API connects different services
A modern application may depend on many APIs at once. An online shopping service, for example, might use one API to verify a customer’s identity, another to calculate shipping costs, another to process payment, and another to send delivery updates.
Each service specializes in a particular function. The shopping application coordinates the results and presents them as part of a unified experience. The payment provider does not need to manage the store’s product catalog, and the shipping service does not need to implement the store’s entire checkout process.
This arrangement is possible because APIs create boundaries between systems. Each service can manage its own data, rules, and internal implementation while exposing only the operations other software needs.
These boundaries also allow organizations to use services maintained by other companies. A business can integrate a mapping service rather than build a global mapping system from scratch, or use an established payment processor rather than develop every aspect of payment infrastructure itself.
However, an API does not make the underlying service independent of its users. Applications may still rely on particular response fields, authentication rules, performance characteristics, or service availability. If the provider changes its interface incompatibly, the applications that depend on it may require updates.
Systems can also become dependent on several services in a chain. A checkout process might require both a payment service and an inventory service. If one service becomes unavailable, the entire process may be delayed or interrupted, even if the other services continue working.
For this reason, developers often design applications to handle failures, retry certain requests when appropriate, set time limits on waiting for responses, and communicate clearly when an operation cannot be completed. Integration is not just about exchanging information successfully under ideal conditions; it is also about behaving predictably when something goes wrong.
Common types of APIs
APIs can be classified according to where they operate, who can use them, and how they define interactions. These categories overlap, so an API can belong to more than one category.
Web APIs allow software to communicate over a network using web technologies. They are widely used to connect websites, mobile applications, cloud services, and external platforms. Many web APIs use HTTP and exchange JSON data, although other protocols and formats are also used.
REST-style APIs follow the principles of Representational State Transfer, an architectural style for networked systems. REST commonly organizes information around resources, such as customers, orders, or products, and uses standard HTTP methods to interact with them. In a well-designed REST API, requests and responses follow consistent rules that help clients understand and use the service. Not every API that uses HTTP is RESTful.
GraphQL is a query language and runtime for APIs that allows clients to specify the data they need from a defined data graph. Instead of relying exclusively on separate fixed response structures for different operations, a client can request particular fields. This can be useful when different applications need different views of related information.
Remote Procedure Call, or RPC, is an approach in which a program invokes an operation provided by another system. The interface may make the remote operation resemble a local function call, even though the request must travel through a communication mechanism and can fail for network-related reasons. Some RPC systems use specialized protocols and compact data formats.
APIs also exist inside operating systems and software libraries. An operating system API lets programs request services such as opening files, creating processes, or accessing network functionality. A library API defines the functions, classes, or other components that developers can use from their own code.
These forms of API differ in their design and implementation, but they serve a shared purpose: defining how software can access capabilities provided by another component without needing to reproduce its internal implementation.
How APIs differ from user interfaces
A user interface is the part of a system through which a person interacts with software. It includes elements such as buttons, menus, forms, and screens. An API, by contrast, provides an interface intended for software to use.
Consider an airline booking system. A traveler might use a website to select a flight and enter passenger details. The website’s user interface helps the traveler make those choices. Behind the scenes, the website may use APIs to retrieve flight information, check seat availability, and create a reservation.
The two interfaces can expose related capabilities while serving different audiences. The user interface is designed around human understanding and interaction; the API is designed around the structured requests and responses that software can process.
An API can exist without a graphical user interface. For example, an automated service may exchange data with another system entirely in the background. Conversely, a user interface can rely on internal program components without making any network requests.
An API is also not the same as a database. A database stores and organizes information, while an API defines how software can access or manipulate data and other capabilities. An API may retrieve information from a database, combine results from several sources, enforce business rules, or perform an operation that does not involve a database at all.
This distinction is important because an API can control how a service is used without exposing its internal data storage or implementation directly.
How APIs handle authentication and security
An API can provide access to sensitive information or operations, so it needs rules governing who is allowed to use it and what they can do.
Authentication establishes or verifies an identity. Authorization determines what that identity is permitted to access. The two are related but distinct: confirming that a request comes from a particular user or application does not automatically mean that the requester should be allowed to perform every operation.
An API may require an access token, a credential that represents an authenticated user, application, or set of permissions. The receiving service validates the token and checks whether the request is authorized. Other authentication mechanisms are also used, depending on the system and its security requirements.
Secure transport is another important protection. HTTPS encrypts data while it travels between communicating systems, helping prevent outsiders from reading or altering the exchange in transit. It does not, by itself, determine whether a user is authorized to access a resource, guarantee that the receiving application is trustworthy, or protect information stored insecurely at either end.
Services also need to validate incoming data. A request might contain an invalid identifier, an unexpected data type, or input designed to exploit a software vulnerability. The server should check that requests meet its requirements rather than assume that a client will always send correct or harmless information.
Other protections may include rate limits, which restrict how frequently a client can make requests; monitoring for suspicious activity; careful handling of credentials; and restrictions on which resources each account can access. Sensitive information should not be exposed merely because a client knows the URL of an API endpoint.
Security responsibilities are shared across the interaction. API providers must protect their services and enforce access rules, while client developers must store credentials appropriately, request only necessary permissions, and handle returned data responsibly.
Why API reliability and compatibility matter
An API is useful only when the software relying on it can understand its behavior and obtain dependable results. Reliability depends on several factors, including network connectivity, server capacity, software correctness, and the availability of any systems on which the service depends.
Network requests take time. A response may be delayed because of congestion, a slow server, or an intermediate service experiencing problems. Sometimes a request never reaches its destination, or the response is lost after the server has already processed the operation.
This creates a particularly important problem for operations that change data. Imagine that an application submits a payment request but loses its connection before receiving the response. The application may not know whether the payment was processed. Simply sending the same request again could produce a duplicate charge if the service does not support appropriate safeguards.
One way to address this problem is idempotency. An operation is idempotent when repeating it with the same intended input has the same effect as performing it once. Reading a resource is generally idempotent, and setting a resource to a particular state can also be idempotent. Creating a new payment or order is not automatically idempotent. Some APIs support idempotency keys, which let clients identify retries as attempts to complete the same logical operation rather than create new ones.
Compatibility is equally important. An API provider may need to improve its service, add new features, or change how information is represented. Changes that preserve existing behavior are generally easier for users to adopt than changes that invalidate previously supported requests.
For example, adding an optional field to a response may be compatible with clients that ignore unknown fields. Removing a field that existing clients require can break those clients. Changing the meaning of a field without changing its name can be even more difficult to detect because the data may still look structurally valid.
Clear documentation, explicit versioning when needed, testing, and advance communication about breaking changes help reduce these risks. Developers also need to avoid assuming that undocumented behavior will remain unchanged.
The role of APIs in modern software
APIs make it practical to build complex applications from components maintained by different teams and organizations. They allow developers to reuse existing capabilities, divide large systems into manageable parts, and update individual components without necessarily rebuilding everything that depends on them.
Their benefits extend beyond convenience. Standardized interfaces can encourage interoperability, meaning that different systems can work together despite differences in their internal designs. They can also support automation by allowing one service to trigger operations in another without requiring a person to manually transfer information between applications.
At the same time, APIs introduce dependencies that must be managed. A system that relies on an external service inherits some of that service’s limitations, availability risks, and rules for access. Data exchanged through an API must also be interpreted correctly, protected appropriately, and handled in ways that respect the rights and expectations of the people it concerns.
Understanding APIs therefore means understanding more than a technical mechanism for sending requests. An API is an agreement between software components about how they can interact. The communication protocols carry the messages, data formats organize the information, and security and compatibility rules help determine whether the interaction is safe and dependable.
When those elements work together, separate applications can function as parts of a larger system, providing capabilities that would be difficult, expensive, or unnecessary to build independently.