TL;DR: A Platform API turns infrastructure and platform capabilities into programmable building blocks.

We have mentioned APIs several times while discussing platform engineering. Before continuing with Platform APIs, it is useful to clarify what we mean by an API and how it can be categorized.

The important point here is that API does not mean Web API.

REST, SOAP, and gRPC are common ways of exposing APIs over a network, but an API is a much broader concept. An API is an interface through which one software component exposes capabilities or resources to another component.

For platform engineering, we are interested less in whether an API uses REST, gRPC, or another protocol, and more in what the API represents and what role it plays in the platform.

With that distinction, we can look at APIs from two different perspectives: the technical layer where they operate, and the scope of what they expose.

This gives us a better foundation for understanding what makes a Platform API different from an API that simply provides a specific application feature.

The term API (Application Programming Interface) predates the web. It originally described interfaces through which software components interacted, including library routines, operating-system services, and compiler-related interfaces on a single machine.

Before modern Web APIs such as REST, SOAP, and gRPC, system integration also used distributed mechanisms such as RPC (Remote Procedure Call), CORBA, COM/DCOM, and EDI (Electronic Data Interchange).

Today, APIs can be viewed from different perspectives. For our discussion, two useful dimensions are where the API operates and how broadly its capabilities are exposed.

1. By System Layer / Execution Context

  1. Web / Network APIs: Remote communication through protocols such as HTTP, HTTPS, WebSockets, or HTTP/2-based gRPC.
  2. Library / SDK APIs: In-process functions, methods, and classes used by applications.
  3. OS / System APIs: Interfaces for interacting with operating-system services, including system calls and platform ABIs (Application Binary Interfaces).
  4. Hardware / Driver APIs: Software interfaces used by operating systems and drivers to access hardware, with underlying mechanisms such as memory-mapped I/O and buses such as PCIe, I2C, and SPI.

2. By Exposure and Business Scope

  1. Platform APIs: Expose core capabilities, resources, lifecycle operations, and extension points that allow developers and automation to build on a platform. Examples: Kubernetes API, AWS EC2/S3 APIs, Salesforce Platform API, Shopify GraphQL API.
  2. Product / Feature APIs: Provide a specific functional capability or business transaction. Examples: Stripe Payment Intents API, Twilio SMS API, OpenWeather API.
  3. Internal / Private APIs: Connect internal services and backend components within an organization. Examples: internal gRPC services and private REST endpoints.
  4. Partner APIs: Provide controlled integration between specific organizations or business systems. Examples: supply-chain EDI integrations and direct B2B banking interfaces.

Back to Platform APIs

A Platform API exposes the core capabilities and resources of an underlying platform as programmable interfaces.

Instead of requiring users to understand the physical infrastructure or internal implementation, the API provides logical resources and operations that can be consumed by applications, automation, controllers, CLIs, SDKs, and other platforms.

A Platform API therefore extends the idea of abstraction. The infrastructure underneath may be complex, but consumers interact with a defined interface.

For platform engineering, four characteristics are particularly important.

1. Declarative State and Control Planes

Many platform APIs expose resources and desired state rather than only providing single-purpose commands.

For example, Kubernetes allows a user to describe the desired state of a resource, while controllers continuously work to reconcile the actual state with that desired state.

This creates a distinction between the control plane, which manages resources and desired state, and the data plane, which performs the actual workload operations.

Declarative APIs also allow asynchronous execution and reconciliation mechanisms such as [Kubernetes Operators}(/posts/2026/kubernetes-operators/), Terraform providers, and cloud control-plane APIs.

2. Extensibility and Inversion of Control

A platform becomes more useful when other systems can extend it without modifying its core implementation.

This requires defined extension points and plugin contracts.

Examples include Kubernetes Custom Resource Definitions (CRDs), admission webhooks, event hooks, and interceptors.

Extensions can also run inside or outside the main process. Examples include in-process plugins, gRPC-based plugins communicating through Unix domain sockets, and WebAssembly-based extension runtimes.

The platform defines the contract, while the extension implements the behavior.

3. Governance, Lifecycle, and Multi-Tenancy

Platform APIs often have stronger requirements for compatibility, lifecycle management, access control, and isolation because many independent consumers may depend on them.

This includes API versioning, backward compatibility, fine-grained Role-Based Access Control (RBAC), resource quotas, tenant isolation, rate limiting, and backpressure.

These controls allow a platform to expose shared infrastructure without giving every consumer unrestricted access to the underlying system.

4. Ecosystem and Toolchain Enablement

A Platform API is often consumed directly by automation, CLIs, SDKs, controllers, and other software rather than primarily through a graphical UI.

This makes the API itself an important part of the developer experience.

Schema-driven APIs can generate or support SDKs, CLI commands, Terraform providers, documentation, and validation mechanisms. Common technologies include OpenAPI, Swagger, and Smithy.

Platform operations also benefit from properties such as idempotency, which allows the same operation to be safely repeated, and event-driven mechanisms such as CloudEvents, webhooks, and Server-Sent Events (SSE).

Back to Certified Cloud Native Platform Engineering Associate Preparation