glossary · technical
API: product management definition
A contract between two systems specifying how to exchange data, where neither side needs to know how the other is built internally.
An API (Application Programming Interface) is a contract: here is the format you send a request in, here is what I return, here are the error codes when something goes wrong. Neither system needs to know how the other is built. As a PM, that contract is the product. It has users (developers), an onboarding funnel, a version lifecycle, and a revenue model. None of that appears in the waiter-brings-food metaphor that gets recycled in most interview prep materials, which is exactly why interviewers at API-first companies follow it up immediately with “so what makes a good API?” A candidate who anchored on the metaphor has nowhere to go.
What the PM actually owns
Three distinct situations put PMs in contact with APIs:
- Managing an API product directly. The API is the thing you ship. Your users are developers. Your onboarding metric is time-to-first-successful-call (TTFC): Twilio measures the time from signup to a developer sending their first SMS or voice call to the minute, and it is their primary developer experience north star. A breaking change to your API schema is equivalent to pushing a UI update that silently breaks every user’s workflow at once.
- Integrating third-party APIs into your product. You are the developer user. Stripe’s sandbox, inline code samples in eight languages, and error messages that tell you exactly what went wrong and how to fix it set the benchmark here. When you evaluate an API vendor, you are reading your own users’ future experience as a signal.
- Explaining APIs to non-technical stakeholders or in an interview. This is a communication problem. The contract framing works better than any analogy because it surfaces the things that actually matter to a PM: format, reliability, versioning, and breakage risk.
REST vs GraphQL: the PM decision
REST uses multiple URL endpoints per resource (/users, /orders) with fixed response shapes. GraphQL uses one endpoint with client-defined queries. The PM tradeoff is not about elegance; it is about who bears the cost:
- REST over-fetches or under-fetches data because the server defines the shape. Simple to cache, simple to version via URL path (/v1/, /v2/).
- GraphQL lets clients request exactly what they need, which cuts over-fetching and reduces round trips. The cost shifts to query complexity, caching difficulty, and a harder deprecation story because there are no discrete versions to sunset.
In an interview, the right answer depends on who the primary developer user is and how predictable their data needs are. A public API serving thousands of unknown integrations usually favors REST for its predictability. An internal API serving one known front end can justify GraphQL’s flexibility.
Versioning as a product decision
API versioning is not an engineering detail. URL path versioning (/v1/) is explicit and cache-friendly; header-based versioning keeps URLs clean but is harder to test, share, and debug. More important than which mechanism you choose is how you handle deprecation. Breaking API changes (removing a field, changing a response schema) can destroy integrations across thousands of developers simultaneously. A deprecation strategy needs to include advance notice, a migration path, and a sunset date that is actually enforced. Interview panels at Twilio and Stripe test this because it is the most common way API PMs destroy trust with developer communities.
Metrics that matter
Total API calls is a weak north star because it counts test runs and spikes. Weekly active tokens (the Moesif framing) is more honest: it captures whether developers are integrating your API into something real and coming back. Webhooks, the inverse of a standard API call where the server pushes an event to your app rather than waiting to be polled, are a quality-of-life signal: unreliable webhook delivery is one of the fastest ways to churn developer customers.
The 2026 shift: APIs as the AI delivery layer
OpenAI, Anthropic, and Google distribute their models exclusively through APIs, making API PM work the direct path to AI PM roles at frontier labs. The business model has shifted with it: usage-based and token-based pricing (per message, per minute, per token) means the PM must understand unit economics at the call level, not just seat-based SaaS math. Ecosystem lock-in now comes from deep integrations and switching cost, not contract terms.
MCP (Model Context Protocol), introduced by Anthropic in late 2024 and widely adopted by 2026, is an emerging API standard specifically for connecting AI agents to tools and data sources. A technical PM at any AI company needs to understand it: connecting an agent to a tool is now a product decision about which contract to expose, not just an infrastructure question. See MCP for the full breakdown.
The viable/lovable lens applies directly here. Viable means developers will pay, integrate, and stay: the market question is whether the problem is real enough to absorb usage-based costs and justify a deep integration. Lovable means meeting developers where they already work (their IDE, their CI pipeline, their terminal), anticipating failure modes before they hit (rate limit warnings before the wall, not after), and not requiring a sales call before sandbox access.