role · role
API product manager interview
The trap in API PM interviews is performing technical awareness without demonstrating product judgment. Interviewers at Stripe, Twilio, Plaid, and Datadog have heard candidates correctly define REST, list versioning schemes, and name idempotency in the first ten minutes, and then watched them fail the actual question: who bears the migration cost when an API changes, and what did you do as a PM to minimize that cost? The role is not a senior engineer with a roadmap. It is a PM who understands what a developer experiences from first docs page to production integration, and who can make product decisions that protect that experience at scale.
The highest-signal questions, with the bar clearly stated
”How do you handle a breaking API change?”
This is the question that most separates candidates who have shipped APIs from candidates who have read about them.
strong
"My first move is to ask whether the break is actually necessary. At Stripe, the constraint is that v1 never breaks, which means PMs learn to expand contracts rather than replace them. If a field like name needs to become first_name and last_name, you add the new fields and deprecate the old one with a sunset header: you don't remove name. Additive changes are almost always possible and almost never the first thing a candidate reaches for. If a break is unavoidable, I want to know exactly which API keys are hitting the affected endpoint before I set any timeline. I'd run an analytics pass and build a tiered outreach list: the top 20 affected integrators get a personal call before any public changelog goes out. Deprecation windows at Twilio and Stripe run 6 to 12 months minimum, with at least two sunset reminders and a migration guide written with DevRel, not just a link to a diff. The goal is zero surprise removals. 'We versioned it' is the beginning of the work, not the end."
weak
"We would version the API and notify developers via email with enough time to migrate." This treats deprecation as a communication problem. It doesn't name who gets contacted, in what order, with what lead time, or how you'd verify migration before sunset. Interviewers hear this and conclude the candidate has never actually shipped an API. It also misses the more important point: the correct answer is often to avoid the break entirely.
”What is your north star metric for a developer API?”
strong
"Time to first call (TTFC) is my primary acquisition-funnel metric. The bar I use: hand the docs cold to a developer who has never seen the API, and if they cannot make a meaningful call in under 30 minutes, the docs are broken. Not the API, the docs. TTFC is within the PM's control in a way that signup conversion is not. For retention, I track integration depth: what percentage of active accounts are using three or more endpoints after 30 days. A developer using one endpoint is an experiment; three endpoints is a dependency. Developer NPS I treat as a lagging satisfaction signal, useful for trend-watching but not as a sprint target. In 2026, I'd add a fourth metric: agent-consumable quality. Can an LLM generate correct SDK calls from the OpenAPI spec without hallucinating field names? That's increasingly how developers prototype against APIs, and an incomplete spec now costs real onboarding time."
weak
"Number of API calls per month." This is a vanity metric. It conflates healthy integrations with retry loops. It doesn't tell you whether developers are succeeding or thrashing. Interviewers at API-first companies will probe immediately and find nothing underneath it.
The versioning philosophy question
Interviewers use versioning to test whether you know real-world divergence, not just the textbook. Two credible schemes exist in production at meaningful scale:
URL path versioning (Stripe’s /v1/, Twilio’s /2010-04-01/): visible in every request, easy to route in infrastructure, creates an obvious migration target. The cost is that it implies a separate API surface: Stripe has maintained v1 since 2011 by adding fields and never removing or renaming them. That is a PM constraint, not an engineering one.
Date-pinned header versioning (GitHub’s X-GitHub-Api-Version: 2022-11-28): version is caller-specified per request, keeps URLs clean, and lets you ship changes on a rolling calendar rather than a named contract. The cost is that it requires callers to actively pin a date and update when they want new behavior, which adds cognitive load on integration.
The PM-level question is not which scheme is correct. It is: who bears the migration cost, and what is your plan to reduce it? Candidates who answer “it depends on the team’s preference” without naming the tradeoff are not yet thinking like API PMs.
Idempotency as a product decision
Stripe’s Idempotency-Key header is a frequent interview topic at fintech API companies because it surfaces PM judgment, not just engineering awareness. The key point: idempotency is a product design decision. A developer who retries a failed payment request without an idempotency key might double-charge a customer. By making idempotency a first-class API primitive with clear documentation and predictable behavior, Stripe shifted that risk off the developer and onto the platform. PMs who understand why that matters to integration reliability (not just how engineers implement it) pass a distinct signal test. The question to expect: “How would you decide whether to build idempotency into a new endpoint?”
Error design: the RFC 9457 signal
Machine-readable error responses are a DX question, not a backend question. RFC 9457 (Problem Details for HTTP APIs, 2023) defines a standard JSON error format with a type URI, title, status, detail, and instance field. An API that returns {"error": "invalid_request"} in 2026 is punishing developers with a support ticket. An API that returns a structured error pointing at the exact field and the exact fix deflects that ticket entirely. Mentioning RFC 9457 by name in an interview signals that you think about error design as a product surface, which is the correct frame.
The 2026 angle: agent-consumable APIs
In 2026, API DX has two distinct audiences: human developers and AI agents. Both matter, and the gap between them is now a PM-level concern. Well-structured OpenAPI specs reduce LLM token consumption by roughly 90 percent compared to raw HTML documentation, because an agent can parse a spec directly rather than scraping prose. Companies like Anthropic publish llms.txt files and expose MCP server surfaces specifically to make their APIs consumable by agent workflows. An API PM who cannot explain what makes an API “agent-friendly” (complete OpenAPI spec, idiomatic error messages, consistent field naming, no undocumented side effects) is missing a major part of the 2026 DX bar.
Stripe’s “never break backward compatibility” constraint is more important in an agent-native world, not less. An agent hitting a deprecated endpoint at 3am has no fallback instinct. It fails silently, or it retries in a loop. The PM who understood that constraint in 2018 as “good practice” needs to understand it in 2026 as a hard reliability requirement.
Developer segmentation and SDK prioritization
Interviewers at companies with SDK suites ask a version of this: “Which SDK would you build first?” The right frame is developer segmentation by language ecosystem, matched against revenue concentration. Enterprise accounts skew Java and .NET; startups skew Python, Node, and TypeScript. If 70 percent of your revenue comes from enterprise and you have no Java SDK, that is the answer. If you’re trying to accelerate top-of-funnel trial volume, a Python SDK with a five-line quickstart beats a complete Java SDK with 200 pages of docs. The PM-level skill is connecting that decision to a specific growth hypothesis rather than shipping the SDK a senior engineer wants to write.
How this role differs from consumer PM
The clearest distinction: your user cannot be observed. A consumer PM can watch session recordings, run A/B tests with statistical significance in days, and ship a fix on Tuesday. An API PM’s user is a developer at another company, integrating on their own timeline, in a production environment you cannot access, with a failure mode that might not surface for weeks. That asymmetry makes design quality and documentation quality upstream product decisions in a way that consumer PM rarely experiences. Interviewers test for this directly by asking how you’d validate a DX change before shipping it.
The viable lens matters here too. API monetization (usage-based pricing, SDK adoption as a switching-cost proxy) and the unit economics of a developer platform (cost per API call, LTV of an integrated account versus a trial account) are first-class PM competencies at Stripe, Plaid, and any infra-adjacent company. Candidates who cannot speak to the business model of the platform they’re interviewing for will not clear the bar.