Products, subscriptions & the portal

B — the subscription is the unit of consumer identity, and everything surgical flows from it. Because each partner enrolled with their own keys, one subscription suspends tonight and reactivates after their fix, while the other partners never learn anything happened. Now price the alternatives, because each is a real thing tired teams do. A fights an identity problem with a network tool: IP ranges shift, NATs and CDNs share them, and the block either misses the partner or catches innocents — and the backend should not be reachable except via the gateway anyway. C is the nuclear option that converts one consumer's bug into every consumer's outage — the exact outcome the gateway exists to prevent. D confuses the brochure with the door; documentation access stops nobody's curl. The habit underneath: any time you cannot act on one consumer, you discover it during an incident, which is why per-consumer credentials are issued on day one.

B — APIs are what you have; products are what you offer. One catalog API can back two products that expose different operations under different terms, so partners meet a read-only, rate-limited offer and internal teams meet the full one — without a second copy of anything. A duplicates the API and its maintenance for no reason; now two models can drift (38c's whole warning). C is not a control at all — "please don't call it" is a suggestion, and a partner's code will call whatever the product exposes. D misplaces the mechanism: a subscription is a consumer's enrolment, not a way to reshape which operations exist — the operations and limits belong to the product, and the subscription just enrols a consumer in it. The product is the altitude where "what you offer" is decided.

Revoke one, bill one, rotate one. Each is an operation on a single subscription that a shared key makes impossible: with one key for everyone, revocation means revoking everyone, usage cannot be attributed, and a leak forces a coordinated rotation across all consumers at once. The two rejects are things a subscription does not do. It does not change what an operation computes — that is backend business logic, on the wrong side of the track's boundary line. And it does not route a consumer to a faster backend; performance tiers, if you built them, would be a product-and-routing decision, not a property of holding a key. The subscription's power is identity and accountability, not application behaviour — keep that line clean.

Line two — and notice it contradicts the very next two lines. A shared key means the gateway sees one anonymous consumer, which makes the per-subscription chart on line four impossible (there are no per-subscription rows), the self-service portal on line three pointless (everyone gets the same key, so why approve individually), and revocation all-or-nothing. "Simpler than managing three subscriptions" is false economy: the portal manages the subscriptions for you, so the shared key saves no real work and destroys throttling, billing, and revocation in one stroke. Run the tape — one partner's key leaks, and now all three must rotate simultaneously, mid-integration, for one company's mistake. The distractors are the plan working: approval is exactly right for a partner product (A), self-service via the portal is more secure than manual key-pasting, not less (C), and per-subscription usage data is precisely what 38h's analytics provide (D).

Concede the pain before defending the keys. The PM is reacting to something real — if onboarding feels like paperwork, that is a legitimate bug — so agree to fix the friction before explaining why the fix cannot be key-sharing. Then run the one bad night, because it converts the abstraction into a story: partner B ships a buggy sync that hammers the API at 2am. With per-partner keys, the machinery handles it in its sleep — B throttles at B's limit, A and C never notice, the usage chart names B, and Monday's email goes to one inbox. With a shared key, the gateway sees one anonymous consumer: the limit throttles all three at once, the chart cannot say who did it, and Monday is three denials and an argument. Same bug, same night — one design produces a line item, the other an incident with diplomacy attached.

Then price the parts the night didn't show. Revocation: keys leak (Class 31's whole curriculum), and a shared key that leaks must be rotated for everyone simultaneously — three coordinated partner deployments for one partner's mistake, which in practice means the leaked key stays valid for weeks. Commercial flexibility: the moment sales wants tiers — the regional chain at 100 a minute, the big marketplace paying for 1,000 — per-partner subscriptions make it a product setting; a shared key makes it impossible. And accountability is Class 32's lesson in partner clothes: an unattributable call is an unattributable cost, and "which partner is worth what" becomes unanswerable at renewal time.

Close by solving the actual complaint. The paperwork is not the keys' fault — it is the process's, and the developer portal already fixes it: partner signs up, requests the product, approval is one click, keys are theirs in minutes — eleven minutes and zero meetings for the case file's third partner. Offer the PM that: "same-day onboarding, and we keep the ability to throttle, bill, and revoke one partner at a time." The sentence that ends the meeting: the keys aren't the paperwork — they're the reason one partner's bad night stays one partner's problem.

Design it as product, subscription, portal, in that order. "First I decide what to offer, not just what I have: I publish a product exposing only the operations external developers should see, with a rate limit, a quota, and approval required — the raw API's full surface never reaches them. Then each developer becomes a subscription: they enrol in the product and get their own key pair, which is what lets me throttle, meter, or revoke any one of them alone. And discovery and sign-up happen in the developer portal — generated docs, an interactive console, and a request-and-approve flow — so they onboard themselves without a meeting." That is the whole design in three nouns, and saying them in order shows you understand the dependency.

Then name what you would refuse: a shared key. "The one thing I won't do is issue a single shared credential to save onboarding effort. It feels simpler and it destroys everything the rest of the design buys — I couldn't attribute usage, couldn't revoke one bad actor without cutting everyone off, and a single leak would force every developer to rotate at once. The portal manages per-developer subscriptions for me, so the shared key saves no real work and forfeits all the accountability." Naming the anti-pattern, and why it is seductive, is what separates someone who has run a public API from someone who has only drawn one.

Close on the property that makes it safe to open at all. "The reason I can open this to strangers without fear is that every one of them is a named, limited, revocable identity from their first call — not a retrofit after the first incident. The accountability is built in on day one, which is exactly what makes 'open it to the public' a calm decision instead of a risky one." That final point — that per-consumer identity is a precondition, not a cleanup — is the senior insight the question is fishing for.