202510011148 API Categories

Not all APIs are created equally. There are different requirements on versioning, compatibility, authorization, and more depending on the context, use, and type of API in question. Below is one possible taxonomy of categorizations, but shouldn't be taken as prescriptive and exhaustive.¹

Name	Description	Example	Contract change cadence	Authorization	Context
Application API	An API that a customer using the front end in a browser would use to get/update data in the application. This traffic goes across the public internet.	A front-end application calls a back-end API for the data it needs.	Fast. Only needs deploy time compatibility. Versioning is not required.	Cookie and possibly JWT based	Public context
Internal API	An API that one service inside of a system would call another service inside the system to get data or perform some type of notification. Ideally this traffic would be internal only (even internal to k8s if both services have been moved there).	Two back-end services call each other.	Medium. Needs internal coordination. Versioning is likely required.	May not need authorization or may use internal API keys	Internal (ideally) system
Public API	An API that our customers would write custom code to use to get/manipulate data within a system. This traffic goes across the public internet.	A customer facing public API.	Slow. Needs external documentation and communication. Versioning is required.	API key associated with marketplace and user	Public customer
Partner API	An API that a partner system uses to interact with a system. The traffic for all current examples of this go across the public internet.	A third party integration (e.g., with a payment processor or email provider)	Slow. Needs external communication and collaboration. Versioning may be required depending on partner.	Depends on partner	Public (probably) system or customer

Adsit, D. (2017, August 7). API Categorization. https://www.pluralsight.com/tech-blog/api-categorization/ ↩