From an anonymous request to a named consumer
The warehouse partner and the courier share one API key. The courier’s script goes wrong, and Ada cannot suspend it without stopping the warehouse too. She needs separate subscriptions and a record of which caller owns each one. A subscription key is useful for this gateway control; it is not proof of the human user’s identity or permission to read a particular order. Keep those checks separate as the partnership grows.
The vocabulary is small and interlocking, and interviews check whether you can walk it without notes:
- API & operations
- The paths and methods APIM exposes. An API can also have an API-scoped subscription or no subscription requirement.
- Product
- A grouping of APIs with settings for subscription requirement, approval and portal discovery. Policies can apply when a request runs in that product's context.
- Subscription
- A named container for primary and secondary keys. Its scope can be a product, one API or all APIs. Give each partner a separate product-scoped subscription in this example.
- Developer portal
- A configurable website where developers can find documentation, request eligible products and test APIs. Visibility and sign-in settings need review before publication.
Products — what you have vs what you offer
APIs are what you have; products are one way to offer them. A product can group the catalog API and require approval for a product-scoped subscription. It does not select a subset of that API's operations. For a partner read-only boundary, prefer a separate partner-facing API with only approved operations, or enforce authorization at API and backend levels. A product-scope policy alone is not enough: Microsoft notes that API-scoped and all-APIs subscriptions bypass product-scope policies.
In this example, the Partner product requires a subscription and approval. A product-scope rate limit can run for calls made with its product keys, while an API-level access rule protects the partner API regardless of subscription scope. On Standard v2, rate-limit-by-key is available but quota-by-key is not. Test the access matrix with product keys, API-scoped keys, all-APIs keys and no key before calling the boundary secure.
Subscriptions — separate keys and counters
An APIM subscription is a named container for a primary and secondary key.1 In our design, each partner gets its own product-scoped subscription, so the gateway can attribute calls made with that key and you can suspend that subscription without revoking the others. A key answers "which partner's subscription is this call counted against?", not "which person is calling, and may they see this order?". That second question is authorisation, and it comes in Part F. A stolen key still identifies the same subscription. Rotate an exposed key promptly; use the second key for a planned switchover only if the partner has already configured it securely. Logs support usage review, but cannot prove an exposed key was never copied or used outside the logged period.
A separate subscription gives you a separate key to suspend.
Separate subscriptions reduce the blast radius of a leaked or misused key. They are a useful operational unit, not proof of caller identity. Part F adds token validation and backend controls; without those, anyone holding a valid key can make a call attributed to its subscription.
Play it through
Configure a protected Partner product with separate partner subscriptions, choose a sample rate limit, then suspend one subscription. The simulation also points out the API-level controls still needed.
The developer portal — onboarding without a meeting
The developer portal is a configurable APIM website for API documentation, testing and access requests.2 For this protected product, a partner can sign in, request a subscription and wait for approval. Publishing a product makes it discoverable in the portal; it is not an access switch at the gateway. Review portal visibility, sign-in, documentation accuracy and test-console behavior before inviting partners.
A self-service request can reduce manual onboarding, but approval, account setup and partner testing still take time. Give each partner clear setup steps and a secure way to receive its keys. The portal can display keys to the authorized account holder; it does not make a copied key safe or replace application authentication.
Three partners, three subscriptions
In the Standard v2 case, Campux publishes a protected Partner product and issues a separate product-scoped subscription after approving each marketplace and the regional chain. It applies a 100-calls-per-minute rate-limit-by-key policy to that product, keyed by subscription ID. There is no quota-by-key in Standard v2. API-level authorization and a limited partner-facing API surface protect the operations even when callers use another valid subscription scope.
If one partner's job loops, its product key can hit its own approximate rate limit. Campux monitors the backend and other partners, then suspends that subscription if needed. If a key leaks, it treats the leak as an incident: rotate the exposed credential, coordinate the partner's cutover to a known safe key, inspect usage and investigate where else the key was stored. Separate subscriptions keep the other partners' keys out of that rotation.
A consumer the gateway can name
APIM now has an API model, policies and separate subscription keys for this partner design. The key lets the gateway attribute a request to a subscription, but not verify the person or app holding it. Part F covers token and backend authentication; Part G covers network paths that might bypass the gateway.
Cutting off one partner without a war room
A partner commits its subscription key to a public repository. Treat the key as compromised: restrict or suspend it, coordinate a replacement with that partner, remove it from the repository and investigate usage. The secondary key helps only if it is known safe and the partner can switch to it; no automatic failover is guaranteed. Other partners keep their own subscription keys, but you still check service load and any shared backend effects.
Continue with a supplied build
Follow the same fictional catalogue through this track. The supplied contract and worked checks let you practise without an Azure estate; the optional import/mock path makes real gateway requests. Each step states what it proves and what it does not.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B — a separate subscription can be suspended separately. APIM stops calls that use the suspended partner keys while other product subscriptions remain valid. Monitor the shared backend to verify other partners' service. IP blocks can affect shared networks, taking the entire API offline affects everyone, and removing portal access does not invalidate an existing key. The key identifies a subscription, not necessarily the physical caller.
A — make the partner surface and authorization explicit. A product groups APIs; it does not pick operations. A product-scope read-only policy applies only in that product's context. Microsoft documents that API-scoped and all-APIs subscription keys bypass product-scope policies, so the write restriction needs an API-level or backend control, preferably with a partner-facing API that exposes only the intended operations. Test every supported access path. A limit remains useful for product-key traffic, but it is not the write authorization boundary.
Suspend, review usage and rotate separately. APIM can distinguish the subscriptions presented on requests. That supports per-subscription reports and coordinated key rotation, but it does not prove the caller's real identity, create a billing system or switch a client automatically to its secondary key. Application behavior and routing require separate design.
# partner onboarding plan
1. Publish a protected Partner product: 100/min by key,
approval required; enforce read access at API/backend.
2. Issue one shared partner key to all partners —
simpler than managing three subscriptions.
3. Partners self-serve via the developer portal:
request the product, we approve, keys issued.
4. Each partner's usage shows on the per-subscription
chart for billing and abuse detection.
Line two. If all partners use one subscription key, APIM records their calls under one subscription. A per-subscription rate limit is then shared, suspending it affects all three, and a leak forces all three to coordinate rotation. Separate subscriptions support separate counters and usage review. Approval and portal self-service can help onboarding, but neither verifies the caller's identity by itself.
Agree that onboarding should be easier. Keep a separate product-scoped subscription for each partner so APIM can count and suspend their keys separately. A shared subscription merges their rate-limit counter and usage records, and a leaked shared key would require every partner to rotate it.
Explain the limit of that design. Separate keys reduce the coordination cost; they do not prove who sent a request or guarantee unaffected partners when the backend is under load. Use application authentication and backend authorization for the partner boundary, and monitor the shared service.
Improve the actual workflow. Document the portal request and approval steps, set an owner and response target, and test onboarding with a partner. Keep credentials out of email and verify the client can rotate to a known safe secondary key before an incident.
Define the API surface first. Expose only intended external operations and enforce authorization at the API and backend. A product groups APIs for discovery and subscription; it does not remove operations from an API or make product-scope policies universal.
Choose the access flow. Publish a protected product, decide whether requests need approval, and give each approved developer or partner a separate product-scoped subscription. Use the portal for documentation and requests, then test sign-in, approval, key handling and the first call. Configure rate limits on supported tiers and validate actual backend capacity.
Refuse a shared key as the sole control. It erases per-partner counters and separate revocation. Also refuse to treat a subscription key as proof of the caller's identity: require suitable app or user authentication, test API-scoped and all-APIs key paths, and restrict direct backend access.
Five things worth carrying out of this part
- An API exposes operations; a product groups APIs; a subscription carries keys; the developer portal supports discovery and access requests.
- A product-scope policy applies to calls in that product context. Protect partner operations at API and backend levels as well, because API-scoped and all-APIs keys can bypass product policies.
- Separate subscriptions support separate counters and suspension. Their keys identify subscriptions, not the physical caller; use stronger authentication when needed.
- Publishing controls portal discovery. It does not itself disable gateway access or replace an approval, authentication or authorization check.
- For a leaked key, rotate or suspend it, coordinate a safe replacement and investigate usage. Secondary-key failover requires client preparation.
- Microsoft's subscription guide documents product, API and all-APIs scopes. API-scoped and all-APIs keys do not apply product-scope policies. A key identifies its subscription, so Microsoft advises against using subscription keys as the sole authentication mechanism. ↩
- Microsoft's product guide distinguishes portal publication from gateway access and explains protected and open products. Review portal access settings before making documentation public. ↩
Package APIs into products, issue subscriptions, and give developers a portal that works.
Play the lesson above to stamp this class.