The objects of a platform
API, proxy, policy, flow, product, application, subscription: the model every API management platform implements, under different names depending on the vendor.
Every API management platform handles the same objects. The names change from one vendor to the next, and so do the screens, but the model is the same everywhere, and knowing it saves half a product training course. It is also the vocabulary of the rest of this guide.
Two chains cross. The exposure chain, which runs from a service to a published API. The consumption chain, which runs from a consumer to a right to call.
Exposure
What the platform publishes
Service
Your implementation
Proxy
The API as it is exposed
Product
One or more proxies, with terms
Consumption
Who has the right to call
Application
The declared client, holder of the credentials
Consumer
The team, the partner, the agent
From the service to the published API
The service is your implementation. The platform knows it only by its address and its contract. It can change language, version or hosting without anything moving in front of it.
The proxy is the API as the platform exposes it. It is the central object, and its name varies a lot from product to product: proxy, API, facade, virtual service. It carries the public address, the version, the routing to the service, and the processing chain applied to every call. A proxy is not one more service: it is a declaration that says how an existing API is presented to the world.
That indirection is what lets you change the implementation without warning consumers, and it is the first reason to have a platform.
The policy and the flow
A policy is a rule applied to a call. Check a token, count a quota, rewrite a header, cache a response, mask a field. Each one is atomic, configurable, and shipped with the product. Writing one by hand is possible everywhere and should stay rare, see what to refuse the gateway.
A flow is the ordered sequence of policies a call goes through. Every platform distinguishes at least two of them, and often three.
| Flow | When it runs | What goes in it |
|---|---|---|
| Inbound | On receiving the call, before the service | Authentication, quotas, validation, filtering |
| Outbound | On the way back from the service, before the consumer | Masking, formatting, cache headers |
| Error | When something fails | Normalised message, logging, return code |
Order matters as much as content. A quota counted after the call to the service protects the contract but not the capacity. A schema validation placed after a transformation validates the wrong document. It is the first thing to read in an existing configuration, and the first to write in a new one.
Scope matters too. A policy can apply to all the traffic of the platform, to a product, to a proxy, or to a single operation. Security and protection policies are placed as high as possible, so that a new API inherits them without anyone thinking about it.
The product, the application, the subscription
These three make up the commercial model of the platform, and they are the least well understood, including internally.
An API product groups one or more APIs together with terms of use: quotas, service level, a price where there is one, related documentation. It is the unit a consumer subscribes to, not the API. The distinction earns its keep as soon as the same API goes into a limited free offer and a generous paid one: one proxy, two products.
An application is the declared client, the one that holds the credentials: an API key, or an OAuth client id and secret. It belongs to a consumer, an internal team, a partner, or an agent. It is not a person, and one team declares several of them, one per environment at the very least.
A subscription links an application to a product. It is the object the gateway consults on every call to answer two questions: is this caller allowed to call this API, and where is it in its quota. It also carries the state, pending, active, revoked, which is what lets you cut a consumer off.
Proxy
An exposed API
Product
Terms and quotas
Application
The consumer's credentials
The test that shows whether an organisation holds to this model: how long does it take to answer "who calls this API, and since when". With the model in place, it is a query. Without it, it is an investigation through logs, by IP address, with gaps.
The names that change from product to product
The same object goes by different names. This table saves redoing the translation at every pre-sales meeting.
| Here | Also called |
|---|---|
| Proxy | API, facade, virtual service, API proxy |
| Policy | Policy, rule, filter, plugin, module |
| Flow | Pipeline, chain, request/response flow, pre/post |
| Product | Plan, tier, API product, package |
| Application | Client, app, developer app |
| Subscription | Contract, entitlement, credential, application key |
Two traps come back. Some products call "API" what others call "product", which changes the meaning of a whole screen. And the word "contract" means, depending on the case, the interface contract, the OpenAPI, or the consumption contract, the subscription. Asking which one is in play saves a meeting.
What this changes in reading the rest
These objects are spread across the three components. Proxies, products and policies are declared in the control plane. The gateway applies them. The portal exposes the products, registers the applications and collects the subscriptions.
An API management product is judged in large part on how clean this model is. Three questions are enough to find out. Can a proxy belong to several products? Does a subscription carry its own quota, or only the quota of the product? And does the same subscription cover an API, an event stream and an agent tool, or does it take three screens?
Updated August 2026.