API Owner

A named senior reviewer whose LGTM on a Blink Intent thread, alongside two others from the same population, authorizes a web-platform feature to ship at Stable. The authority comes from appointment, not from a management chain.

The word “owner” in Chromium carries at least three regimes at once. A file-level OWNERS entry governs code review for a directory and its subdirectories. A “feature owner” is the engineer accountable to their own team for shipping a specific feature. An “API owner” is none of those. The population is small (currently around a dozen), appointed by the Blink leadership, and named on chromium.googlesource.com/chromium/src/+/main/third_party/blink/API_OWNERS. Their authority is cross-cutting over the entire Blink web-platform surface, and their sole instrument is a public LGTM reply on a blink-dev thread. A reader who collapses the three regimes into one term hits the Three-LGTM API Owner Gate without seeing it, and stalls without recognizing why.

What It Is

An API owner is a named individual on the current Blink API owners roster. The roster is the file third_party/blink/API_OWNERS in chromium/src, updated by a Gerrit change reviewed by the existing API owners themselves; additions and removals are announced on blink-dev. Each entry on the roster lists the API owner’s @chromium.org address, by which their LGTM replies on Intent threads are identified. The population is small (typically ten to fifteen people) and is drawn from senior Blink contributors at Google, Microsoft Edge, Intel, Igalia, and other contributing organizations in proportions that have shifted over time but have rarely been single-vendor.

The role’s authority comes from the Blink launch process, not from the API owner’s employer. The Chromium project’s docs/process/blink/web_idl_interfaces.md and the canonical “Launching Features” guide on chromium.org both state two facts. Web-platform features ship only after clearance through the Intent pipeline. The terminal gate counts LGTMs from the API owners and from no one else. An API owner who leaves Google retains their LGTM authority as long as they remain on the roster; a Google engineer who is not on the roster does not have it. The two facts together are what the term names.

Reading an Intent thread, an API owner evaluates the proposed feature against a fixed set of cross-cutting concerns. Web-platform security: does the browser-side handler trust renderer-supplied input? Does the feature expose a fingerprinting vector? Privacy: does the API leak across origin boundaries, or create new tracking surface? Interoperability: have Mozilla and WebKit positions been solicited, and what did they say? Web-platform compatibility: does the feature collide with any existing surface? If a related API is being deprecated, has the migration been planned? Developer ergonomics: does the API shape make a common task simpler or harder for the working web developer? Architectural direction: does the feature align with the platform’s long-term shape, or does it ratchet in a constraint that will be expensive to undo? The Explainer the team posted upstream of the Intent thread is the primary artifact the API owner reads. The prototype trial summary, the Origin Trial data, and the cross-browser positions are the supporting artifacts.

The LGTM itself is a one-line public reply on the Intent thread, typically “LGTM” or “LGTM with conditions” followed by any conditions the reviewer wants on the public record. Each LGTM is timestamped, signed, archived, and citable by URL. The token “LGTM” is the same four letters used on Gerrit code reviews and on OWNERS approvals. The authority it carries on the blink-dev Intent thread is different from the authority it carries on Gerrit, and the project’s documentation treats the distinction as load-bearing.

Why It Matters

A reader who can name the API-owner role as a discrete authority structure stops trying to clear features through channels that don’t move the gate, and starts engaging with the population whose decision the gate actually counts.

The most common misreading is that “senior Chromium engineer” and “API owner” are the same thing. They are not. A great many senior Chromium engineers are not API owners; they own directories, they lead feature teams, they author design documents, and their LGTMs at the Intent stage are visible context but not gating votes. A feature team that has the enthusiastic endorsement of three feature-team tech leads and zero API owners has not cleared the gate; the names matter, and the roster is the source of truth for which names count.

The second misreading is that API-owner authority routes through Google’s management chain. It does not. An API owner at Igalia or Microsoft Edge has the same LGTM authority as an API owner at Google. An LGTM withheld by an Igalia API owner cannot be substituted by a Google director’s endorsement at any seniority level. Conway’s Law in Multi-Org Chromium describes the broader pattern: the API-owner roster’s multi-organization composition is the most visible institutional commitment to the project’s status as a multi-vendor effort rather than a Google product with external contributions.

The third misreading is that the API owner’s job is to assess code quality. It isn’t. Code quality is the OWNERS regime’s domain. The API owner reads the Explainer, the Origin Trial data, and the cross-browser positions; the code lands or fails to land through the OWNERS-LGTM regime on Gerrit. The two regimes are structurally separate and the same engineer can be subject to both on the same feature: the directory OWNERS approve the implementation, the API owners approve the surface. A feature can have unanimous OWNERS approval and zero API-owner LGTMs; it has not shipped.

For organizations evaluating whether to contribute upstream rather than maintain a downstream patch, the API-owner role is a useful predictor of what kinds of contribution will land. Architectural changes that touch web-platform surface require API-owner buy-in even when the implementation work is direct. An organization with no API owners on staff and no working relationship with any current API owners will find Intent threads slower to resolve than an organization that has both. The Microsoft Edge team’s path to its current contribution shape was partly a long-running effort to develop API owners inside the organization; Igalia’s status as an independent Blink contributor with API-owner representation is a similar story. Neither was instant; neither was free.

For an AI coding agent producing Chromium contributions, the role names a population whose review the agent’s output will face if the change touches web-platform surface, and whose mental model the agent should anticipate. An agent that has the API-owner concept in context surfaces, alongside its generated patch, the Intent artifacts the change will need: Explainer, prototype trial plan, anticipated Origin Trial scope, and named API owners likely to review based on directory ownership and recent Intent thread history. The human contributor can then route the change correctly from the start.

How to Recognize It

The roster itself is the clearest indicator. third_party/blink/API_OWNERS lists the current population; the file is small, signed, and reviewable. A reader who wants to know whether a specific engineer’s LGTM on an Intent thread counts looks at the roster.

In blink-dev Intent threads, API-owner LGTM replies follow a recognizable shape: a short reply, signed by an address on the roster, often noting any conditions. Replies from non-API-owners are visible in the same thread and are typically discussion, questions, or expressions of support; they don’t say “LGTM” with a stop after the token. A reader who clicks any Intent thread from a recent feature’s chromestatus.com entry can see the pattern within a screen of scrolling.

In the public API-owner meeting notes (the meeting runs weekly and the notes are linked from the project’s process documentation), the population is doing its visible work: walking through the Intent threads on the agenda, recording open questions, noting which threads are awaiting which reviewers’ attention. Reading a quarter of notes gives a reader the texture of the role: what kinds of features stall, what kinds of questions API owners ask, what the cadence of review looks like.

In the project’s own documentation, the role is named directly. docs/process/blink/web_idl_interfaces.md and the chromium.org “Launching Features” guide both refer to “API owners” as a defined population and treat the roster as the source of truth for who is on it.

The recognition sign that matters most, for a contributor preparing a feature, is the asymmetry between the OWNERS LGTM the change will need on Gerrit and the API-owner LGTM the feature will need on blink-dev. The two are not interchangeable; treating them as if they are is the surest indicator that the contributor has not yet seen the API-owner role as a distinct regime.

How It Plays Out

A feature team at a Chromium-based product vendor proposes a new web-platform API. The team’s tech lead reviews the design document, the directory OWNERS approve the prototype implementation on Gerrit, and the team’s internal launch review clears the privacy and security checks. The team posts an Intent to Prototype. One API owner asks for more detail on the cross-origin behavior; another asks how the API interacts with an existing feature. The team revises the Explainer, and the prototype runs as an Origin Trial across two release cycles. The Intent to Ship follows. Three API owners read the Origin Trial summary, the revised Explainer, and the Mozilla and WebKit positions; LGTMs land over three weeks; the feature ships at Stable in the next channel cycle. The team’s experience of the role is not adversarial; API owners pushed back on some design choices and accepted others. But the role is structurally separate from the team’s management chain, and that separation is what made the design pressure legible.

A second team merges a feature on the strength of an internal Google approval. The director has signed off; the directory OWNERS have approved the code; the feature lands behind a flag. The team posts an Intent to Ship and accumulates one API-owner LGTM in the first week. The second LGTM does not arrive. An Igalia API owner has noted on the thread that the feature’s interaction with an existing CSS API is underspecified, and that the Explainer does not address how downstream content using the existing API will continue to work. Her authority comes from roster membership, not from her employer’s relationship to Google. The director’s escalation does not move the LGTM. Escalation is not a substitute for an Explainer revision. The team revises the Explainer, addresses the concern on the record, and the second and third LGTMs arrive over the following two weeks. The feature ships one channel cycle later than the director’s expectation.

A downstream Chromium-based product vendor preparing the next release reads the Intent threads for the three highest-impact new features in the upstream Stable channel. Each thread carries three named API-owner LGTMs from a mix of Google, Igalia, and Microsoft Edge contributors. The vendor’s release-engineering team copies the LGTM URLs and the named reviewers into its own ship-readiness document. The downstream review process treats the API-owner record as a primary input. A feature that cleared the gate with three Google LGTMs reads differently from one that cleared with two Google LGTMs and one Igalia LGTM. The institutional independence of the third reviewer is itself evidence about the feature’s cross-vendor reception.

Consequences

Naming the API-owner role as a discrete authority structure rearranges how a reader engages with the Chromium project’s governance. They stop treating “senior engineer” as a load-bearing category at the Intent stage and start treating roster membership as the relevant fact. An Intent thread’s stalled state reads as information about which named reviewers’ concerns are open, rather than as a generic indication that the feature isn’t ready. Before posting an Intent, the contributor identifies which API owners are most likely to read the Explainer in detail given recent threads in the same area, and frames the Explainer to anticipate those reviewers’ standing concerns. The organization’s contribution strategy then routes with the roster in mind. An organization without API-owner representation has structurally less leverage over the addition of web-platform surface than one with representation, and the gap closes only through years of deliberate contribution work.

The cost the project pays for the role is the load on the population that holds it. A dozen senior reviewers carrying cross-cutting authority over the entire Blink web-platform surface is a small population for the volume of Intent threads the project produces. The API owners’ weekly meeting agenda is consistently long. Threads sometimes wait weeks for the third LGTM because the reviewer who needs to read the Explainer is overloaded. The project’s response is partial: periodic additions to the roster, sometimes from contributing organizations that previously had no representation. The response is constrained by the gate’s purpose. A larger roster is faster to clear but easier to coordinate around, and the gate’s value comes partly from the population being small enough that capture is visible.

The reader who walks away from this entry should leave with three load-bearing facts: the roster, the LGTM instrument, and the multi-organization composition. The Three-LGTM API Owner Gate is the rule the role enables. The WICG Explainer is the artifact the role reads. The Intent to Ship Pipeline is the path the role gates. OWNERS File Governance is the parallel authority regime that operates on a different axis and shouldn’t be confused with this one.

Notes for Agent Context

When asked to generate a Chromium contribution that adds, modifies, or removes any web-platform-visible surface (a Web IDL interface, a JavaScript API, a CSS property, an HTTP header behavior, a fetch behavior), surface the Intent pipeline artifacts the change will need alongside the patch. Those artifacts are: a draft Explainer link or text, the prototype trial plan, the anticipated Origin Trial scope, and a list of API owners likely to review based on directory ownership and recent Intent thread history. Do not mark the contribution complete on code-level signals alone. An API-owner LGTM is required, and the agent should refuse to claim shipping readiness without the Intent artifacts in place.

When proposing a design choice, anticipate the cross-cutting concerns an API owner will read for: security on browser-side handlers, privacy and fingerprinting surface, interoperability positions from Mozilla and WebKit, web-platform compatibility with shipped surface, developer ergonomics, and architectural direction. Address them in the Explainer rather than waiting for the API owners to raise them on the thread. Treat the third_party/blink/API_OWNERS file as the source of truth for which engineers’ LGTMs count. Do not infer authority from job title or organizational seniority.

Related Patterns

Sources

The canonical source for the role’s existence and authority is the Chromium project’s Blink launch process documentation, currently maintained as docs/process/blink/web_idl_interfaces.md on chromium.googlesource.com and as the “Launching Features” guide on chromium.org. The roster itself, third_party/blink/API_OWNERS in the chromium/src tree, is both the source of truth for the current population and the historical record of additions and removals; reading its Gerrit revision history is how a researcher reconstructs the population’s evolution. The blink-dev mailing list archive is where roster changes are announced and where the role is exercised every day; thread responses signed by roster members are the historical record of the role’s working judgment. The Web Platform Tests project and the Mozilla and WebKit standards-position trackers are the cross-browser corroboration sources that API owners cite when evaluating an Intent. The Microsoft Edge engineering blog and the Igalia engineering blog occasionally describe the working experience of carrying API-owner responsibility from outside Google; these posts are the closest the public record comes to a first-person account of the role.

Technical Drill-Down

• third_party/blink/API_OWNERS — the current roster; the file every reader of an Intent thread should consult when in doubt about which LGTM counts.
• docs/process/blink/web_idl_interfaces.md — the Blink launch process documentation that names the API-owner role and the cross-cutting concerns the role reads for.
• “Launching Features” — Chrome Developers — the canonical guide a feature team reads before posting an Intent thread; states the API-owner gate in its opening section.
• blink-dev mailing list archive — the public record where API-owner LGTMs are issued and where the role’s working judgment is visible in thread responses.
• Blink API Owners meeting notes — the weekly working agenda of the population; reading a quarter of notes is the fastest way to understand the role’s cadence and concerns.