An API, or Application Programming Interface, is a defined way for one software system to request information or an action from another. It describes what the requesting system can ask for, what information it must provide, and what response to expect. The systems can communicate without either one knowing how the other is built.
APIs are used inside operating systems and software libraries as well as between networked services. A web API commonly uses HTTP, but API is the broader idea. The MDN API glossary explains the general concept; the OpenAPI Specification describes a standard way to document HTTP APIs.
How an API works
A client sends a request that follows the API contract. The provider checks the request and the caller’s permissions, performs an allowed operation, then returns a response or error. The contract may define available operations, required fields, data formats, authentication and error responses. An API may read data, change a record, or do both.
In an HTTP API, an endpoint identifies a resource or operation. The request and response may carry structured data such as JSON. Documentation helps developers understand and test the interface before connecting it to another application.
An illustrative business example
Illustrative example: An online order system checks whether an item is available before confirming an order. It sends the inventory service a request with the item and quantity. The service returns an availability result; if the caller has permission and the workflow allows it, a separate operation may reserve the stock. The order system continues or sends an exception to a person for review.
API, REST and JSON
An API is the interface software uses to interact. REST is one architectural style used to design some networked APIs. JSON is one possible format for request or response data. A REST API may use JSON, but neither REST nor JSON defines every API.
An API does not replace the business rules behind it. Teams still need to decide which system owns each record, who can request each operation, and what happens when data is missing or a request fails.
What an API does not solve by itself
A working connection is one part of an integration. Data meanings must match, access must be limited to the right users and operations, and failures, retries, duplicate requests and interface changes need owners. These details affect whether a connection can be supported in daily operations.
When separate systems need to exchange data in a business workflow, technine.io’s system integration and workflow automation service is a relevant place to review the scope.
Frequently asked questions
Is an API the same as a website?
No. A website presents an interface for people; an API presents a defined interface for software. A website may use APIs behind the scenes or provide an API to other applications.
Does every API use REST or JSON?
No. APIs can use different designs and data formats. REST and JSON are common in web development, but neither is required for the general concept of an API.
Does connecting two APIs complete a system integration?
Not necessarily. The connection also needs agreed data definitions, permissions, error handling, testing, and an owner for ongoing changes and support.
Related reading: See What is MCP? for a protocol that helps AI applications connect to tools and context, and What are Agent Skills? for reusable task instructions.
Primary sources: MDN: API glossary · OpenAPI Specification · Roy Fielding’s REST dissertation