API Interview Questions

A web API is an API accessed over the internet using HTTP, letting a client, like a web browser or mobile app, communicate with a server. It's the most common type of API used in modern application development, powering everything from a weather app fetching forecast data to a website loading product listings.

REST stands for Representational State Transfer, an architectural style for designing networked applications. A REST API follows REST's principles, organizing functionality around resources (like users or orders), accessed through standard HTTP methods, and is stateless, meaning each request contains all the information needed to process it.

GET retrieves data without modifying anything. POST creates a new resource. PUT updates an existing resource, typically replacing it entirely. PATCH partially updates a resource. DELETE removes a resource. These methods map to the basic operations most APIs need to support for managing data.

An endpoint is a specific URL where an API can be accessed to perform a particular operation, like /api/users to get a list of users or /api/users/123 to get a specific user. Each endpoint typically corresponds to a resource or action the API exposes.

A request is what the client sends to the server, including the HTTP method, the endpoint URL, headers, and sometimes a body containing data. A response is what the server sends back, including a status code indicating success or failure, headers, and typically a body containing the requested data or an error message.

JSON (JavaScript Object Notation) is a lightweight, text-based data format that's easy for both humans to read and machines to parse. It's widely used in APIs because it maps naturally to data structures in most programming languages and is more compact and simpler to work with than older formats like XML.

A status code is a three-digit number returned in an API response indicating the outcome of a request. 200 means success, 201 means a resource was created, 400 means the client sent a bad request, 401 means authentication is required, 404 means the resource wasn't found, and 500 means an unexpected server error occurred.

Headers carry metadata about the request, like the content type being sent or an authentication token, in key-value pairs. The body carries the actual data payload being sent, typically used with POST, PUT, and PATCH requests to include the data being created or updated.

API authentication verifies the identity of whoever is making a request, ensuring only authorized clients or users can access an API's data or functionality. Without it, anyone could call an API and access or modify data they shouldn't have permission to touch.

An API key is a unique string of characters assigned to a client that identifies and authenticates it when making requests, usually passed in a header or as a query parameter. It's a simpler alternative to more complex authentication schemes, though it doesn't identify an individual end user the way something like OAuth does.

A public API is openly available for external developers to use, often with documentation and self-service access, like a weather service's API. A private API is intended for internal use only, within a company or between its own systems, and typically isn't exposed for outside developers to consume.

API documentation explains how to use an API, including available endpoints, required parameters, expected request and response formats, and authentication requirements. It's essential because without clear documentation, developers can't effectively integrate with an API even if it's technically well-built.

A query parameter is a key-value pair appended to a URL after a question mark, used to filter, sort, or modify what data a request returns, like /api/products?category=shoes&sort=price. Multiple query parameters are typically separated by an ampersand.

A synchronous call blocks the calling code until the API responds, meaning nothing else happens until the response arrives. An asynchronous call lets the calling code continue running other tasks while waiting for the response, which is especially important in user interfaces so the application doesn't freeze while waiting for a slow API call.

An SDK, or Software Development Kit, is a package of tools, libraries, and sometimes sample code that makes it easier to work with a specific API or platform. Rather than manually constructing raw HTTP requests, a developer can use an SDK's pre-built functions to interact with the API more conveniently.

Rate limiting restricts how many requests a client can make to an API within a given time period, protecting the API's infrastructure from being overwhelmed and ensuring fair usage across all clients. When a client exceeds the limit, the API typically responds with a 429 (Too Many Requests) status code.

A GET request retrieves data and should not have any side effects on the server, with parameters typically passed in the URL. A POST request creates new data or triggers an action with side effects, with data typically sent in the request body rather than the URL, and unlike GET requests, POST requests generally aren't cached by browsers.

The payload is the actual data content returned in an API response body, as opposed to the metadata carried in headers or status codes. For a GET request fetching a user's profile, the payload would be the JSON object containing that user's actual details.

API versioning is the practice of managing changes to an API over time without breaking existing clients that depend on an older version, commonly done by including a version number in the URL (like /api/v1/users) or in a request header. It lets an API evolve while giving existing integrations time to migrate to newer versions.

The client is the application or system that initiates a request, like a mobile app or a web browser. The server is the system that receives the request, processes it, and sends back a response, typically hosting the data or business logic the client wants to access.

CRUD stands for Create, Read, Update, and Delete, the four basic operations most applications need to perform on data. A well-designed REST API typically maps these operations directly to HTTP methods: POST for create, GET for read, PUT/PATCH for update, and DELETE for delete.

The Content-Type header tells the receiving party what format the data in the request or response body is in, like application/json or application/xml. It allows the server or client to correctly parse the body content, since sending JSON data without declaring it could cause the receiving side to misinterpret it.

A webhook is a way for a server to proactively send data to another system when a specific event happens, rather than the receiving system having to repeatedly ask (poll) for updates. Instead of a client calling an API to check for new data, the server calls a URL the client has registered whenever relevant data changes.

A 4xx status code indicates a client-side error, meaning the request itself had a problem, like invalid input or missing authentication. A 5xx status code indicates a server-side error, meaning the server failed to process an otherwise valid request due to a bug, an outage, or an unexpected condition on its end.

A stateless API means the server doesn't retain any information about a client between separate requests. Each request must contain all the information the server needs to process it, like an authentication token, rather than the server relying on a remembered session from a previous request.

An absolute URL includes the full address, like https://api.example.com/v1/users, while a relative URL only includes the path, like /v1/users, assuming a base URL is already established elsewhere. API documentation commonly uses relative URLs alongside a clearly stated base URL to keep examples concise.

A timeout is the maximum amount of time a client will wait for a server to respond before giving up and treating the request as failed. Setting reasonable timeouts prevents an application from hanging indefinitely if a server is slow or unresponsive, letting the client handle the failure gracefully instead.

The base URL is the common root address shared by all of an API's endpoints, like https://api.example.com/v1. Every specific endpoint is then reached by appending a path to that base URL, giving the API a consistent, predictable structure across all its resources.

REST organizes an API around resources (nouns) manipulated through standard HTTP methods. RPC (Remote Procedure Call) style APIs are organized around actions (verbs), like /getUserDetails or /createOrder, more directly mirroring function calls. REST tends to be more standardized and predictable across different APIs, while RPC can feel more natural for actions that don't map cleanly to CRUD operations on a resource.

Content-Length tells the receiving party how many bytes are in the response body, letting the client know when it has received the complete response, particularly useful for larger payloads or when a connection might be interrupted partway through.

A null or empty response occurs when a request is valid but there's no data to return, like searching for a resource that doesn't exist. A well-designed API distinguishes this clearly, often returning a 404 status for a specific resource that isn't found, or an empty array with a 200 status for a list query that simply has no matching results.

In casual usage, the terms are sometimes used loosely, but strictly, a plain HTTP API is any API that communicates over HTTP, while a REST API specifically follows REST's architectural constraints, like statelessness and resource-based design. Not every HTTP-based API is genuinely RESTful, even if it uses similar conventions like JSON and standard status codes.

The Accept header tells the server what response format the client is able to understand, like application/json or application/xml. If an API supports multiple response formats, it can use this header to decide which format to return, though most modern APIs default to JSON regardless.

Latency is the time it takes for an API to respond to a request, measured from when the request is sent to when the response is received. It matters because high latency directly affects the user experience of any application depending on that API, and for APIs called many times in sequence, even small delays per call can add up significantly.

An internal API is used only within an organization, connecting a company's own systems and services. An external API is exposed for use outside the organization, by partners or independent third-party developers. External APIs generally require much more careful documentation, versioning discipline, and security review since they're consumed by parties the organization has less direct control over.

I'd use plural nouns for resource collections (/users, not /user), nest related resources logically (/users/123/orders for a specific user's orders), avoid verbs in URLs since HTTP methods already convey the action, and keep the structure predictable and consistent across the whole API so developers can guess an endpoint's shape from patterns they've already seen elsewhere.

PUT replaces an entire resource with the data provided, meaning any fields not included in the request are typically reset or removed. PATCH applies a partial update, modifying only the specific fields included in the request while leaving the rest of the resource unchanged. Choosing the wrong one can lead to accidentally wiping out data a client didn't intend to touch.

I'd use appropriate HTTP status codes paired with a consistent, structured error response body, typically including an error code, a human-readable message, and sometimes field-specific validation details. Consistency matters so client applications can reliably parse and handle errors the same way across every endpoint rather than needing custom logic per endpoint.

An idempotent operation produces the same result no matter how many times it's performed, GET, PUT, and DELETE are expected to be idempotent, while POST typically isn't. It matters because network issues can cause a client to retry a request, and idempotency guarantees that retrying a PUT or DELETE won't cause unintended duplicate effects the way retrying a non-idempotent POST might.

OAuth 2.0 is an authorization framework that lets a user grant a third-party application limited access to their resources on another service without sharing their actual password, using tokens with defined scopes and expiration. It's more sophisticated than a simple API key, supporting scenarios like a user authorizing one app to access their data on another app's behalf, with fine-grained, revocable permissions.

A JWT is a compact, self-contained token that encodes claims (like a user ID and expiration time) in a signed, verifiable format. After a user authenticates, the server issues a JWT, and the client includes it in subsequent requests' Authorization header, letting the server verify the token's signature and extract the user's identity without needing to query a session store for every request.

Common approaches include offset-based pagination (page and limit or offset and limit query parameters) or cursor-based pagination (returning a token pointing to the next set of results). Cursor-based pagination tends to perform better and handle data changes more gracefully for very large or frequently changing datasets, while offset-based pagination is simpler to implement and reason about for smaller datasets.

HATEOAS (Hypermedia as the Engine of Application State) is a REST constraint where an API response includes links to related actions or resources a client can take next, letting a client navigate an API dynamically rather than hardcoding every possible URL. It's one of the more advanced and less commonly fully implemented REST principles in practice, though many APIs implement simpler hypermedia elements like pagination links.

Filtering and sorting are typically exposed through query parameters, like /products?category=shoes&sort=-price for filtering by category and sorting by price descending. For more complex search needs, a dedicated search endpoint or query language might be needed, but simple filtering and sorting on a resource's own list endpoint covers most common use cases cleanly.

REST is a lightweight architectural style typically using JSON over HTTP, favoring simplicity and flexibility. SOAP (Simple Object Access Protocol) is a stricter, XML-based protocol with a formal contract (WSDL) defining exactly what operations and data structures are available, often used in enterprise systems requiring stronger formal contracts, built-in error handling, or transactional guarantees that REST doesn't natively provide.

I'd favor additive changes, adding new optional fields or endpoints, over breaking changes whenever possible, since existing clients continue working without modification. When a genuinely breaking change is unavoidable, versioning the API and maintaining the old version for a defined deprecation period gives clients time to migrate rather than breaking them without warning.

Rate limiting sets a hard cap on the number of requests allowed in a given time window, rejecting requests beyond that limit. Throttling can be more nuanced, sometimes slowing down responses or queuing excess requests rather than outright rejecting them, to smooth out traffic spikes without necessarily blocking the client entirely.

A common pattern uses multipart/form-data encoding for the request body when uploading a file directly through the API, or alternatively, the API returns a pre-signed URL that lets the client upload the file directly to cloud storage, which offloads the actual file transfer from the API server and scales better for large files.

API mocking creates a simulated version of an API that returns realistic sample responses without a real backend implementation existing yet. It's useful because it lets frontend and backend teams work in parallel, the frontend team building against the mocked API's contract while the backend team builds the real implementation behind it.

That includes validating and sanitizing all input to prevent injection attacks, enforcing HTTPS to encrypt data in transit, implementing proper authentication and authorization on every endpoint, rate limiting to prevent abuse, and being careful not to leak sensitive information in error messages that could help an attacker understand the system's internals.

Authentication verifies who is making a request, confirming their identity. Authorization determines what that authenticated identity is allowed to do, checking their permissions against the specific action or resource they're trying to access. An API needs both: knowing who someone is doesn't automatically mean they should be allowed to do everything.

I'd establish a standard envelope structure, consistent field naming conventions (like always camelCase or always snake_case), a consistent way of representing dates and null values, and a predictable error structure applied everywhere. Consistency reduces the cognitive load for developers integrating with the API, since they can apply the same parsing logic across every endpoint rather than relearning a new pattern for each one.

A dedicated bulk endpoint accepting an array of items in the request body is a common pattern, returning a per-item result so the client can see which individual records succeeded or failed rather than the whole batch failing or succeeding as one unit. Designing clear semantics for partial failure, whether the whole batch rolls back or succeeded items are kept, matters as much as the endpoint's basic structure.

Content negotiation is the process by which a client and server agree on the format of the data being exchanged, typically using the Accept header for the response format and the Content-Type header for the request format. Most modern APIs default to JSON, but content negotiation matters more for APIs that genuinely support multiple formats for different clients.

I'd favor smaller, more efficient payloads to reduce data usage, design endpoints to be idempotent where possible so a retried request after a dropped connection doesn't cause duplicate effects, and support conditional requests (using ETags or Last-Modified headers) so the client can avoid re-downloading data that hasn't changed since its last successful sync.

An ETag is a response header representing a specific version of a resource, typically a hash of its content. A client can send that ETag back in a subsequent request's If-None-Match header, and if the resource hasn't changed, the server responds with a 304 Not Modified status instead of resending the full payload, saving bandwidth.

I'd include a machine-readable error code for programmatic handling, a clear human-readable message explaining what went wrong, and where relevant, specific details about which field or parameter caused the issue. Vague, generic error messages like 'something went wrong' force developers to guess at the actual problem, which slows down integration and support significantly.

A hard delete permanently removes a record from the database, with no way to recover it. A soft delete marks a record as deleted (often with a flag or timestamp) without actually removing it, keeping the data recoverable and preserving referential integrity for related records. APIs often use soft deletes for data with audit or compliance requirements, even though the DELETE HTTP method itself doesn't distinguish between the two internally.

An API gateway centralizes cross-cutting concerns, authentication, rate limiting, request routing, and logging, so individual microservices don't each need to reimplement that logic separately. It also gives external clients a single, stable entry point even as the underlying microservices architecture changes, decoupling the public API surface from internal service boundaries.

GraphQL lets clients request exactly the fields they need in a single query, rather than making multiple REST calls or receiving fixed response shapes that might over-fetch or under-fetch data. It's a strong fit for complex frontends with varied data needs across different views, or when reducing the number of network round trips genuinely matters, though it adds complexity around caching and can make server-side performance harder to reason about compared to REST's more predictable per-endpoint behavior.

I'd profile to find the actual bottleneck first, often a slow database query or an N+1 query pattern, before applying caching at the appropriate layer, whether that's response caching, a CDN for static or infrequently changing data, or an application-level cache like Redis for expensive computed results. Adding pagination to endpoints returning large datasets and reviewing whether the endpoint is doing more work than the client actually needs are also common, high-impact fixes.

First-party clients might use a simpler internal authentication scheme trusted implicitly, while third-party consumers typically need OAuth 2.0 with well-defined scopes, so each third-party integration only gets access to what it explicitly needs. Designing both to converge on the same underlying authorization model at the API layer keeps the system consistent even though the authentication flow differs between the two kinds of consumers.

I'd communicate the change well in advance with a clear deprecation timeline, provide detailed migration documentation and, where feasible, a compatibility layer or automated migration tooling, and monitor usage of the deprecated version to know which clients still need to migrate before finally removing support. Rushing a breaking change without adequate notice tends to cause far more damage to trust and integration stability than the delay of doing it properly.

I'd instrument APIs with structured logging including request IDs that can be traced across services, metrics on latency and error rates broken down by endpoint, and distributed tracing for requests that span multiple services. This combination lets you quickly pinpoint whether a production issue is isolated to one endpoint, one downstream dependency, or a broader systemic problem.

I'd typically expose a REST API for standard request/response and batch-style access, paired with a separate WebSocket or Server-Sent Events channel for real-time updates on that same data, rather than trying to force both patterns through one interface. Keeping them as clearly separate access patterns, sharing the same underlying data layer, tends to be cleaner than a single hybrid endpoint trying to serve both needs.

I'd weigh the number of external consumers, the need for self-service developer onboarding, sophisticated usage analytics, and monetization or tiered access requirements against the added cost and complexity a full API management platform brings. A small number of trusted internal or partner consumers often doesn't need the same tooling investment as a genuinely public-facing API platform with many independent third-party developers.

I'd layer testing across unit tests for individual business logic, integration tests verifying actual endpoint behavior against a test database, contract tests ensuring the API's shape matches what's documented and what consumers expect, and load testing to verify performance holds up under realistic or peak traffic conditions before the release goes out.

I'd isolate tenant data clearly, whether through a tenant ID on every request and query, separate database schemas, or fully separate databases depending on the isolation and compliance requirements. Authorization checks need to verify more than that a user is authenticated. They also need to confirm the user belongs to the tenant whose data they're trying to access, since a missed check here is a serious cross-tenant data leak risk.

I'd think about caching at multiple levels, a CDN for public, rarely changing data, an application-level cache like Redis for expensive computed responses, and HTTP-level caching headers (Cache-Control, ETag) that let clients and intermediate proxies cache appropriately on their own. Getting cache invalidation right, so stale data doesn't get served after an update, is usually the harder part of the problem compared to setting up the caching itself.

API-first means designing an API's contract before building the implementation behind it, which tends to produce cleaner, more thoughtfully designed interfaces and lets frontend and backend teams work in parallel against an agreed contract. It's worth the cultural investment for organizations building many APIs consumed by multiple teams or external partners, though it can feel like unnecessary process overhead for a small team building a single, simple internal service.

I'd quantify the current cost of the status quo, duplicated API implementations across teams, integration friction between internal systems, security incidents traced back to inconsistent authentication practices, and project how that cost compounds as the number of APIs and teams grows. Pairing that with concrete examples of specific pain points a governance program would have prevented makes the investment tangible rather than an abstract argument about best practices.

I'd establish a consistent, company-wide deprecation policy, a minimum notice period, clear communication channels, and standard tooling for tracking which consumers still depend on a deprecated API, rather than leaving each team to handle deprecation inconsistently. Predictability in how deprecation is handled builds trust with both internal and external API consumers, who can then plan their own migrations with confidence.

I'd weigh REST's broad familiarity and simplicity for public-facing and generally accessible APIs, GraphQL's efficiency for complex, client-driven data needs particularly in frontend-heavy applications, and gRPC's performance and strong typing advantages for high-throughput internal service-to-service communication. Rather than mandating a single standard for every use case, I'd typically set REST as the default with clear guidance on when GraphQL or gRPC is the better fit for a specific scenario.

I'd establish mandatory security baselines, authentication standards, input validation requirements, rate limiting, that every API must meet regardless of which team built it, enforced through automated security scanning in the CI/CD pipeline rather than relying purely on manual review. A single inconsistently secured API can become the weakest link exposing the whole organization, so baseline security can't be left to each team's individual judgment alone.

I'd track metrics like API adoption and usage growth, developer satisfaction and time-to-first-successful-call for new integrations, error rates and latency across the ecosystem, and how much duplicate functionality exists across independently built APIs. These give a fuller picture of ecosystem health than any single API's individual metrics, surfacing systemic issues like poor discoverability or inconsistent standards that a per-API view would miss.

I'd weigh the number and diversity of API consumers, both internal teams and external partners, against the ongoing investment a quality developer portal requires, interactive documentation, sandbox environments, self-service key management. It pays off clearly once onboarding friction is visibly slowing integration velocity across many consumers, but it's often premature investment for an API with only a handful of known, well-coordinated consumers.

I'd weigh how pricing affects the incentive to experiment and build on the platform against the genuine cost of serving API traffic, since pricing too aggressively early can suppress the ecosystem growth a platform business depends on. A generous free tier for experimentation and low-volume use, with clear, predictable pricing as usage scales, tends to balance adoption and revenue better than aggressive metering from the very first call.

I'd treat this as an organizational risk requiring deliberate intervention rather than letting it drift, either by formally reallocating resources to the owning team commensurate with its actual criticality, or by transitioning ownership to a team better positioned to maintain it, with a clear, planned handoff rather than an ad hoc one. Leaving a critical dependency under-resourced because reallocating ownership feels disruptive tends to produce a much bigger disruption later, at a worse time.

I'd weigh the integration cost of inconsistency, every team needing custom logic to work with every other team's API, against the genuine cost of forcing standardization onto domains with real, legitimate differences in their data and workflows. A shared standard for cross-cutting concerns like authentication, paired with domain-specific flexibility in resource modeling, tends to capture most of the integration benefit without forcing an artificial uniformity that doesn't fit every business unit's needs.

I'd weigh the integration overhead and network chattiness of many fine-grained APIs against the coupling and reduced team autonomy that comes with consolidating them into shared, broader services. The right answer often depends on how independently the underlying domains actually need to evolve, forcing artificial consolidation onto genuinely independent domains tends to recreate the same coordination problems the fine-grained split was meant to avoid.

I treat accumulated inconsistency as a compounding cost, every new integration and every new engineer onboarding pays a small tax for the lack of standardization, and that tax grows as the ecosystem grows. I'd rather introduce coordination incrementally, starting with the highest-friction inconsistencies, than either ignore the problem indefinitely or attempt a disruptive, all-at-once standardization effort across an already-large ecosystem.

I'd assess whether request/response APIs are genuinely still the right fit for every use case the organization has, or whether certain workflows would be better served by an event-driven approach, without assuming either pattern is universally superior. Piloting event-driven patterns for a genuinely well-suited use case, rather than mandating a wholesale shift, gives the organization real evidence before committing to a broader architectural direction.

I'd build the case around concrete, demonstrated pain points already visible, frontend teams struggling with over-fetching or chaining many REST calls, rather than chasing GraphQL because it's a newer, more discussed technology. A pilot on one or two high-friction integration points gives real data on developer experience and performance before committing to a broader migration across the organization.

I try to get them involved early in decisions with organization-wide impact, like reviewing a proposed new authentication standard or weighing in on a versioning policy change, rather than only working within the scope of their own team's API. Asking them to think through how a design decision plays out for consumers they'll never personally meet builds the broader platform-thinking instinct over time.

I favor a small number of firm, high-impact standards, authentication, security baselines, core naming and versioning conventions, paired with real flexibility everywhere else, like how a team structures its own resource models for its specific domain. Over-standardizing low-stakes decisions burns organizational goodwill that's better spent enforcing the handful of things that genuinely protect the platform and its consumers.

I look for the smallest safe shortcut rather than either blocking the urgent need entirely or abandoning good practice altogether, sometimes that means a temporary, clearly documented endpoint outside the standard framework, with an explicit commitment and timeline to bring it in line once the immediate pressure passes. Being transparent with stakeholders about exactly what corner is being cut, and why, tends to preserve trust even when the honest answer is 'not the ideal way, for now.'

Signals include recurring integration friction between teams building genuinely incompatible APIs, growing security incidents traced back to inconsistent practices, or teams routinely reinventing functionality that already exists elsewhere in the organization because nothing is discoverable. Rather than waiting for a major incident to force the issue, I'd rather introduce structure incrementally as the organization's complexity genuinely demands it.

I'd quantify the current cost of the status quo, time lost to integration friction, duplicated effort across teams building similar API functionality independently, and project that cost forward against expected growth in the number of teams and APIs. Pairing that with a concrete example, a specific incident or duplication of effort that shared standards would have prevented, makes the investment tangible rather than an abstract argument about best practices.

I weigh how someone reasons about tradeoffs, like when to centralize a concern versus letting teams solve it independently, over how many API design patterns they can recite from memory. I ask about a real architectural decision they made that didn't pan out as expected, since how someone talks through a genuine setback and what they'd do differently tells me far more than a rehearsed success story.

I weigh the ongoing cost of maintaining an aging, poorly understood API against the cost and risk of replacing it. If it's stable and rarely touched, I'd rather document it properly and leave it alone than risk destabilizing something working purely for the sake of tidiness. Once it becomes a recurring source of incidents or blocks other teams from moving forward, that's when the cost of leaving it alone finally outweighs the risk of change.

I lead with business impact in plain language, which systems or customer-facing features are affected and for how long, before getting into technical root cause. Detailed technical explanation belongs in a follow-up postmortem for those who want it, since overloading an in-the-moment update with implementation detail usually adds confusion rather than the clarity stakeholders actually need.

I push for that knowledge to become documentation, architectural decision records, and shared ownership of the most critical APIs well before it becomes urgent, rather than staying locked in one or two people's heads. Pairing a senior engineer with someone earlier in their career on the trickiest production issues, rather than always having the expert handle it solo, spreads the knowledge naturally instead of relying on a single point of failure remaining available indefinitely.

Standardization earns its place where inconsistency creates genuine risk or cost, authentication, security baselines, cross-team integration patterns. Beyond that, I'd rather let teams move quickly within their own domains than impose uniformity that mostly serves aesthetic consistency. The test I use is whether a given standard is protecting something concrete or just making the ecosystem look tidier.

I try to lead with specific, observable consequences rather than a general critique, pointing to the integration friction or maintenance cost the current design is actually producing rather than framing it as a judgment on the original decision. Most engineers respond well to being shown a concrete problem and invited to help solve it together, rather than being told after the fact that their design was wrong.

The work shifts from personally designing most APIs to multiplying the organization's effectiveness, through better standards, mentoring, and removing organizational obstacles that slow teams down when building or consuming APIs. I measure my own impact less by APIs I've personally designed and more by whether the broader ecosystem and the teams working within it are genuinely healthier than before I got involved.