Interview Prep · Lesson 05
Business & product sense for API design
Every API exists to serve a business goal and a set of consumers. Knowing who consumes the API, what outcome they need, and who pays for it is not a soft skill add-on — it changes the design fundamentally. Senior interviewers consistently reward candidates who open with business context.
By the end you'll be able to
- Name the three API business models and explain what each implies for design choices.
- Sketch a usage-based metering tier table and connect it to API rate limiting and SLA design.
- Open an interview design answer with a business-framing question that impresses senior interviewers.
The API as a product, not a plumbing detail
A product is something you ship to users to deliver value, track adoption, and iterate on. For most of software history, APIs were treated as plumbing — necessary but invisible, designed by engineers for engineers. The "API-first" movement, driven by companies like Stripe, Twilio, and Plaid, reframed this: the API is the product. Customers buy access to the API; the developer experience of calling it determines retention; the API contract is the promise the company makes to the market.
Think of a power grid. Your appliances do not care what fuel drives the turbines — they just need reliable 230 V at the outlet. The power company's product is the standardised electrical interface, not the generation equipment behind it. Stripe's product is not its payment processors; it is the predictable, reliable API that lets any developer charge a card in three lines of code.
The three API business models
The audience for an API determines almost everything: authentication complexity, latency requirements, versioning stability, documentation quality, and error message design.
| Model | Who calls it | Design implications |
|---|---|---|
| Private / internal | Your own engineering teams | Lower documentation bar; breaking changes tolerable with coordination; can use internal auth (mTLS, service tokens); can expose richer internal details; latency SLA driven by product goals |
| Partner | Approved third parties (B2B integrations, whitelabel customers) | Contractual stability required; dedicated versioning; partner-specific auth (OAuth, signed keys); tailored rate limits per partner tier; partial data exposure (partners see less than internal) |
| Public / open | Any developer who signs up | Maximum backward-compatibility pressure; excellent error messages (no internal context); generous but enforced rate limits; full OpenAPI documentation; deprecation notices with long windows; abuse resistance |
These models are not mutually exclusive. A company might expose the same underlying capability at all three levels: an internal API with full access, a partner API with scoped access, and a public API with metered free access. This is sometimes called a layered API program.
Monetisation and metering
Public and partner APIs are often monetised by usage. This is called usage-based pricing or consumption pricing. The API provider tracks API calls (or a proxy unit like "messages processed" or "GB transferred"), and the consumer pays per unit or per tier. This model directly ties revenue to API call volume, which creates strong incentives to design APIs efficiently: an API that wastes calls costs the consumer more money and drives them to competitors.
Quota tiers in practice
Most metered APIs publish a tier table. Rate limiting (covered in rel-03) enforces the quotas at runtime. Here is a representative tier structure:
| Tier | Monthly price | Requests / month | Rate limit | SLA uptime |
|---|---|---|---|---|
| Free | $0 | 10 000 | 10 req/s | none (best effort) |
| Starter | $49 | 500 000 | 100 req/s | 99.5% |
| Growth | $299 | 5 000 000 | 500 req/s | 99.9% |
| Enterprise | custom | unlimited | custom | 99.99% w/ credits |
Each tier is also an implicit SLA commitment. A 99.9% uptime SLA (the Growth tier above) means no more than 8.7 hours of downtime per year. If the provider misses it, the consumer may be entitled to service credits. SLAs are covered in depth in lesson 10; the point here is that the tier you sell determines the operational reliability you must engineer.
Requirements gathering: start from the business goal
Most API designs fail not because of technical choices but because the designer started with technical questions ("should I use REST or GraphQL?") before answering business questions. A better framework asks three questions first:
- Who is the consumer? Internal team, external partner, or public developer? This determines auth model, documentation depth, versioning policy, and error message quality.
- What outcome do they need? A payment partner needs reliable transaction confirmation, not just an HTTP 200. A developer tooling API needs predictable latency. A data export API needs consistency over speed. The outcome shapes SLAs and error semantics.
- Who pays, and how? Internal APIs are funded by the engineering budget — cost is measured in developer time. External APIs are funded by customers — cost is measured in usage. The payment model determines whether you need metering, quotas, and usage dashboards.
When an interviewer says "design an API for X," pause before touching endpoints and say: "Before I jump to endpoints, let me clarify the business context — is this for internal teams, external partners, or public developers? Who is the primary consumer and what outcome are they trying to achieve? And is this going to be metered / monetised?" This one move signals product maturity, avoids designing the wrong thing, and gives you a richer answer. Most candidates skip straight to routes. Interviewers remember the ones who didn't.
Weaving business framing into your answer
Here is the same design question answered at two different levels. The question: "Design the API for a notifications service."
Shallow answer (common): "I'd have a POST /notifications endpoint that takes a user ID, a channel (email/SMS/push), and a message body. A GET /notifications/{id} to check status."
Business-framed answer (strong): "Let me start with who's calling this API. If it's internal teams only, we can afford a simpler design — internal auth, generous rate limits, and we can break things with a coordinated deploy. But if partners or third-party apps need to trigger notifications on behalf of our users, the bar rises: we need scoped OAuth tokens so partners can only notify their own users, a strict quota per partner to protect downstream SMS costs, and a versioned contract because we can't ask 50 partners to redeploy simultaneously. I'd also ask: is notification volume billable? If so, we need a usage event emitted per notification to feed the metering pipeline. Given those constraints, here's the resource model…"
Designing an API without asking why it exists or who the consumer is. The result is usually a CRUD mapping of the database schema — technically coherent but wrong for the use case. An internal analytics API has no need for pagination defaults tuned for mobile app performance. A public developer API has no need for internal monitoring fields in every response. Business context collapses the design space to a manageable size.
Do ask the business model question before designing anything. Don't open with "I'll use REST with versioned URLs." Do connect rate limiting, SLAs, and auth model back to which tier/consumer model you're targeting. Don't design a public-grade API (expensive to maintain, full docs, backwards-compatible forever) when you're building an internal tool that three engineers will use. Match operational cost to actual need.
🧠 Quick check
1. A company is building an API that external paying customers will integrate into their own products. Which business model applies?
External paying customers who integrate the API into their products are partners: they have a contractual relationship, scoped access, and typically negotiated SLAs. A fully open API anyone can sign up for without a sales conversation would be "public."
2. What does a 99.9% uptime SLA imply operationally?
99.9% uptime = 0.1% downtime = 0.001 × 365 × 24 h ≈ 8.76 hours per year (about 43.8 minutes per month). SLAs express calendar-time availability, not per-request availability — the service can fail briefly and recover; what is counted is total outage time.
3. You are designing a public API. A user's request fails because they exceeded their quota. What is the best HTTP status code to return?
429 is the correct status for rate limiting / quota exhaustion — the user is authenticated and authorised but has exceeded their allowed call volume. A 503 implies infrastructure failure. A 403 implies the user lacks permission entirely, not that they have run out of quota.
4. An interviewer asks "design a file-storage API." What is the most impactful first question to ask?
The consumer model and monetisation question collapses the design space immediately: it determines auth model, rate limits, versioning policy, error message quality, and whether you need a metering pipeline. Format and protocol questions come later and are much easier once the context is clear.
✍️ Exercise: open a design answer with business framing
An interviewer says: "Design an API for a weather data service."
Write the first 3–4 sentences of your answer, covering: who the consumers are, what outcome they need, the business model, and at least one design implication that flows directly from your business framing.
Model answer:
Before designing endpoints I want to clarify the business context. Weather data is typically sold at all three tiers: an internal API for the company's own product teams (no monetisation, generous limits), a partner API for B2B integrations like smart-home device manufacturers who need higher rate limits and SLA guarantees they can put in their own contracts, and a public developer API for indie apps and students with a free metered tier.
The public tier has the most design consequences: we must version the contract because we cannot coordinate deploys with thousands of unknown consumers, enforce per-key quotas and emit usage events to a billing pipeline, surface human-readable error messages (developers will not have internal context when something goes wrong), and provide a full OpenAPI spec. For the partner tier we additionally commit to an SLA — say 99.9% monthly uptime — which means we need to engineer for that, and we expose a slightly wider dataset (historical data, ensemble models) not available on the free tier. With that in mind, here is the resource model...
Rubric: ✓ names at least two consumer types ✓ connects consumer type to at least one concrete design decision (versioning / auth / metering / SLA) ✓ signals awareness that different tiers require different operational commitments ✓ uses business framing to narrow the design space before touching endpoints — all four = strong opening.
Key takeaways
- An API is a product — it has consumers, a value proposition, and a business model. Design it like one.
- The three models (private, partner, public) dictate auth complexity, versioning stability, documentation depth, and error message quality.
- Usage-based monetisation ties rate limits and SLAs to tiers; the SLA you sell determines the reliability you must engineer.
- Before touching endpoints, ask: who is the consumer, what outcome do they need, and who pays for it?
- Opening an interview answer with business context — before REST vs GraphQL — signals senior product maturity and is consistently rewarded.
Sources & further reading
- Google API Design Guide — includes discussion of API as a product and resource-oriented design
- Stripe Engineering — Payment API design principles
- Increment Magazine — "APIs as infrastructure" (Stripe, Twilio case studies)
- Nordic APIs — API business models and economic rationale