Designing API Products and Plans for Tiered Partners
A logistics platform wants to sell API access in three tiers: Starter (free, 1,000 calls/day, read-only tracking), Growth (paid, 100,000 calls/day, tracking plus label creation), and Enterprise (custom, unlimited within fair-use, all operations plus webhooks). There are 40 prospective customers, and sales wants to onboard them without engineering involvement. Today every customer gets a hand-configured key and a bespoke rate limit set by an engineer, taking about 3 days each. The platform also needs to show usage per customer for billing and must be able to suspend a non-paying customer immediately. Operations worry that a self-service flow will let customers exceed capacity.
1. Design the API product and plan structure. Explain how it removes engineering from onboarding while preserving operational control.
Read the worked answer
Model the offering as one API product per tier (or one product with three plans), each plan encoding its own quota, rate limit, and allowed operations:
- Starter plan: 1,000 calls/day, read-only tracking operations only.
- Growth plan: 100,000 calls/day, tracking plus label creation.
- Enterprise plan: fair-use limits, all operations including webhooks, negotiated per contract.
Operations are gated at the plan level, so a Starter key cannot call label creation even if it guesses the path - the entitlement, not the client, enforces scope. Quotas and rate limits live in the plan, so onboarding becomes: sales assigns the customer to a plan and issues an application/key through the portal. No engineer edits a limit; the plan already defines it.
Operational control: capacity risk is bounded because each plan has a defined ceiling and Enterprise is contractually fair-use. Per-application limits prevent one customer from consuming another's allowance. Suspension is a state change on the application (disable the key), effective immediately at the gateway, without touching other customers. Usage metering per application feeds billing. The design converts bespoke configuration into a small number of governed templates - the engineering effort moves from per-customer to per-tier, once.
2. Sales wants a fourth 'Trial' tier with 30-day access and no payment. What governance and abuse risks does this introduce, and how would you mitigate them?
Read the worked answer
Risks:
- Resource abuse: free trials attract scripted signups that consume gateway capacity and could degrade paid customers.
- Data exposure: trial users may reach tracking data for shipments they do not own if object-level authorization is weak.
- Lifecycle drift: trials that never expire become permanent free accounts, eroding revenue and inflating usage.
- Billing/usage ambiguity: trial usage mixed into metering can distort invoices if not separated.
Mitigations:
- Define Trial as a plan with a hard low daily quota, read-only operations, and a mandatory expiry enforced by lifecycle state (auto-suspend at day 30), not by manual review.
- Require verified signup and per-application keys so abuse is attributable and revocable; apply stricter rate limits than Starter.
- Ensure tracking access is scoped to the trial customer's own shipments via object-level checks, not just a valid key.
- Tag trial applications so usage is metered separately and excluded from paid billing.
- Monitor signup velocity and per-key anomaly patterns; cap the number of trial applications per organization.
Governance-wise, the trial tier should be reviewed like any product: documented owner, lifecycle stage, published limits, and a defined exit path to Starter or Growth.