Types of APIs
Grouping APIs by Audience and Access
There are several types of APIs, and the simplest way to group them is by who may use them and how access is controlled. This grouping is about the business and security side of an interface, not its technical design.
Every API has a provider, which builds and runs it, and consumers, which send requests to it. The type describes the relationship between the two. A provider can offer an interface to the whole internet, to its own staff, to a small group of business partners, or to clients as a bundle of several other services.
The architectural style of an API, such as REST or GraphQL, is a separate question. A public API can be built in REST, and a private API can be built in GraphQL. For the basic concept, see what an API is.
Public and Private APIs: Open Versus Internal Access
Public APIs, sometimes called open APIs, are available to any developer who wants to use them. Typical examples include map services, weather data, currency conversion and payment or messaging platforms that let outside developers build on their products. Public APIs usually require registration and an API key, and they set limits on how many requests each client can send.
Private APIs, also called internal APIs, are used only inside one organization. A hosting company might run an internal API so that its billing system, control panel and support tools can exchange customer data. Outsiders cannot call it, and the company can change it without publishing new documentation for external users.
The difference is less about the technology and more about the promise made to users. A public API is a product with a published contract. A private API is an internal arrangement that teams can adjust as needed.
Partner and Composite APIs: Shared and Combined Services
Partner APIs are shared only with selected business partners, usually under a contract or agreement. They sit between public and private: they are documented for outside companies but not open to everyone. A payment processor might give a checkout vendor access to extra endpoints for approving refunds, while keeping them unavailable to general developers.
Composite APIs combine several calls or services into a single request. Instead of asking for a customer, their orders and their invoices in three separate requests, a client can ask one composite endpoint and receive all three in one response. This reduces round trips for clients and lets the provider hide the complexity of the underlying services. Some documentation calls this pattern an aggregated or orchestrated API.
Example: One Hosting Company, Several API Types
Consider a hosting company that offers four interfaces. Its public API lets any customer check account status and manage domains with a documented key. Its private API connects the billing system to the control panel, so that paid plans are switched on automatically. A partner API gives a website builder the right to create accounts for that builder's own users. A composite endpoint returns a customer's plan, usage and open support tickets in one response for the company's dashboard.
Each interface serves a different audience, so each has a different level of documentation, access control and stability guarantees. Customers rely on the public API, so changes are announced in advance. The private API can change more freely, because only the company's own teams depend on it. Connecting outside tools to these interfaces is covered in API integrations.
Frequently asked questions
Is a public API always free to use?
No. A public API is open to any developer, but that does not mean it is free. Some providers offer a free tier with limits on requests, others charge per use, and some require a paid plan for production traffic. Read the provider's terms and usage limits before building on a public API, because they can change over time.
Can an API belong to more than one type?
Yes. A provider can offer the same functions through a public version for all developers and a partner version with extra features or higher limits. A single system can therefore expose several interfaces, each with its own type. Classification depends on who may use the interface and under what terms, not on how the interface is built.