API Product
What Is It For?
- Presents gateway APIs as products on the portal storefront
- Packages multiple proxies/proxy groups into one product
- Defines Free / Flat rate / Metered / Tiered plans with quota, rate limit, and approval
- Separates discoverability (visibility) from access (plan approval)
- Tracks subscriptions through organization-owned applications
Who Uses It?
-
Portal / product administrators: To create, package, plan, and publish products
-
Developers: To discover products and subscribe with an app + plan
-
Support / operations: To verify subscription and usage summaries
Info
Packaging inventory (which proxy is in which product?) → API Catalog.
App lifecycle / Unregister → Application Management.
Test→Prod → Application Promote.
Live quota/traffic → Traffic & Usage.
:::
Access
- Manager: Portal → API Products
- Developer Portal storefront: top menu APIs
- Requires portal product-management roles
Model
API Catalog (proxy / proxy group)
│ Select APIs from the Catalog
▼
API Product (proxyRefs + OpenAPI + Plans)
│ subscribe
▼
Portal App (organization) + Plan → ApiProductAppRegister
│
▼
App credential + ACL (packaged proxies)
- A subscription = (application, this product, chosen plan)
- Quota applies per subscription
- The same proxy can belong to multiple products
- With live WAITING/APPROVED subscriptions you cannot remove APIs from the package; you can only add
Create (wizard)
Creates an unpublished product. Typical steps: General → APIs → API Spec → Plans → Environment → Summary.
| Topic | Code reality |
|---|---|
| API selection | 1..n proxyRefs from Catalog (proxies and/or groups together) |
| Spec | Product-owned uploaded OpenAPI (JSON/YAML). Multi-proxy cannot derive from a single proxy swagger |
| Publish | After create the product is Unpublished; publish separately |
Manager detail tabs
API Specification and test console
Documentation management
| Tab | Contents |
|---|---|
| API Specification | Product OpenAPI / endpoints |
| Documentation | Portal documentation pages |
| Files | Downloadable files |
| Plans | Active/Retired plans; Duplicate; approval/pricing; quota and rate limit are now defined through Limit Profile references (Request Rate, AI Token Budget); on exceed Block 429 or Continue & charge must agree with the referenced profile |
| Subscriptions (N) | Read-only: org → app → plan + status + usage summary |
| Security | Consistent ACL-managed auth across packaged proxies; publish blocked when not ready |
| Visibility | Discoverability (access/approval stays on plans) |
| Danger Zone | Unpublish / Delete |
Manual plan approvals are not done on the product Subscriptions overview; they are under API Product App Registers / Approval Requests.
Plan types
| UI (EN) | Meaning |
|---|---|
| Free | Free |
| Flat rate | Fixed fee (not labeled “Subscription”) |
| Metered | Usage-based |
| Tiered | Tiered pricing |
Consumers pick exactly one plan per subscription. Approval is per plan: Auto approval / Approval Required. Product-level auto-approve is deprecated and should not be taught.
Limit Profiles
A plan's quota and rate limit are defined through two independent Limit Profile references instead of raw numbers — one for Request Rate, one for AI Token Budget:
| Value | Meaning |
|---|---|
| Off | No ceiling from this family. |
| Plan | References a published, platform-scope plan from the Limit Plans catalog. |
Rules enforced when choosing a profile:
- Only platform-scope, published plans are selectable — a project-scope or still-draft plan cannot be referenced (the picker only ever offers valid ones).
- The selected plan's family must match the reference's own family (Request Rate / AI Token Budget).
- The product plan's own on-exceed setting (Block 429 or Continue & charge) must agree with the referenced profile's overflow posture: Continue & charge only pairs with a Count-Only (or alert-only) profile; Block 429 only pairs with a blocking profile. The screen warns before you can save a mismatched combination; the server also refuses it with
400 Bad Request. - A profile revision published later is not re-checked against the product plans already referencing it — this reverse-dependency check is not available yet.
During the transition, the legacy quota/rate-limit fields stay populated behind the scenes purely so the existing enforcement mechanism keeps working — they are not separately managed on this screen.
Impact Preview on Change
Changing a published plan's Limit Profile reference or on-exceed setting shows a confirmation, before the save goes through, with how many subscriptions and applications the change would affect. Declining the confirmation cancels the save.
Typed Limit Binding
When a subscription is approved, the plan's Limit Profile references materialize into one application-wide binding per family for the subscribing application — applying to all of that application's traffic, not just this product's.
- A plan change moves the same binding to the new plan; its counter is not reset.
- When a subscription ends, its binding is handed over to another still-active subscription of the same application, if one exists; otherwise the binding ends with it.
- One application and one plan family always resolve to one binding. If two different subscriptions want different profiles for the same family, the existing binding is kept — the approval screen surfaces this as a warning, and an operator who wants the new profile makes that an explicit choice with Switch the Profile (see Approval Requests).
- The binding of a portal application used across multiple projects is kept under the admin project.
Version Upgrade
On upgrade, product plans that already carry quota/rate-limit numbers are converted automatically into platform-scope Request Rate Limit Plans and pointed at from their product plan; plans with no limit stay Off. This conversion only creates the plans themselves — it does not automatically create the application-level binding for subscriptions that were already approved by then. A system administrator produces those bindings by first previewing the result (dry run), then triggering the actual run.
Throughout this transition — after the plans are created but before an administrator runs the binding backfill — a subscription that was already approved has no application-level binding yet, so nothing is enforced through this path for it until the backfill runs; the subscription keeps working exactly as it did before the upgrade in the meantime. See Enforcement on the Limit Plans page for what a binding does once it exists.
Visibility
| Type | Meaning |
|---|---|
| Public | Discoverable by everyone |
| Only logged in Organizations | Discoverable to signed-in orgs |
| Authorized Organizations | Discoverable to an authorized org list |
Visibility = discovery. Subscribe approval is on the plan.
Danger Zone
- Unpublish: Hides from the storefront; existing subscriptions may keep working
- Delete: Blocked while active subscriptions exist
Developer Portal product page
| Tab | Gate |
|---|---|
| Overview | Description + plan cards |
| API Specification | Auth summary, endpoints, Try It |
| Documentation | Published docs; locked if unpublished |
| Applications & Plans | Signed in — Register / + Add plan / Unregister by app |
| Dashboard & Traffic | Signed in + Features Analytics on — dashboard + traffic table |
| Files | File list |
Subscriptions start on the consumer side (product page or My Apps wizards). Manager app edit only supports Unregister.
Publish checklist
- Package APIs from Catalog
- Upload OpenAPI
- Define at least one Active plan (quota/rate/approval)
- Ensure Security is ready
- Set Visibility
- Publish
- Optionally verify packaging on API Catalog