Who owns the API: how to stop integration conflicts between teams
Why API design disputes slow down companies more than technical debt, and how to establish clear ownership without creating a bottleneck committee.
The most common source of integration delay I see in growing technology companies is not a technical problem. It is an ownership problem. Two teams need to exchange data. One team expects a certain shape. The other team publishes something different. Three weeks later there is a meeting, a compromise, and a third shape that neither team wanted but both can live with. The integration ships late.
This pattern repeats itself because companies grow their APIs the same way they grew their internal tools - whoever needed something, built it. No one paused to establish who has the final word when two teams disagree about an interface.
Why API ownership matters more as you scale
When a company has five engineers, informal agreement is fast and cheap. When it has fifty, the same informal agreement becomes a political negotiation, because the cost of changing an API is now much higher - there are more consumers, more tests to update, more documentation to fix.
The worst situation is no declared owner at all. Both teams think of themselves as co-owners, which means neither feels responsible for maintaining backward compatibility or making hard decisions. The API drifts, accumulates workarounds, and eventually someone proposes a full rewrite - which is another way of saying the ownership problem was never solved.
The two failure modes
I see companies fall into one of two traps when they try to fix this.
The first is the platform team bottleneck. A central team is given ownership of all APIs. Every change requires their review. They become a queue. Teams learn to avoid touching shared interfaces because the process is too slow, so they copy data instead of integrating - which creates a different and worse form of coupling.
The second is the producing team owns everything. The team that publishes the API makes all decisions about its shape. Consumers have no formal channel to request changes or raise compatibility concerns. This works until the producing team optimizes for their own convenience and inadvertently breaks several downstream systems.
A pattern that works
The approach I recommend is producing team owns, consuming teams have a registered voice.
Concretely: the team that produces the API is the decision-maker. They are responsible for versioning, backward compatibility, and change communication. But consuming teams formally register their use of each API endpoint - ideally in a shared document or a lightweight service registry. Before a breaking change, the producer is required to consult each registered consumer and give adequate notice.
This keeps the decision authority clear while preventing the producer from making changes in isolation. It also makes the actual usage of each API visible, which is useful when deciding what to deprecate.
Schema-first as a practical discipline
One concrete tool that helps: schema-first API design. Before any code is written, the teams agree on the request and response shapes in a shared document - an OpenAPI spec, a Protobuf definition, an Avro schema. The schema becomes the contract. Both teams test against it.
This does not eliminate disagreements, but it moves them to a much cheaper point in the process. Disagreeing over a document is faster and less painful than disagreeing after three weeks of implementation work.
What to put in place
If you recognize the ownership problem in your company, these are the practical steps that help:
- Decide explicitly: for each shared API, who is the producing team and who are the consuming teams.
- Create a lightweight registry - even a shared spreadsheet with API name, owner, and registered consumers works to start.
- Add a change communication norm: any breaking or potentially breaking change requires notification to registered consumers at least two weeks in advance.
- Start schema-first for new APIs. Do not try to retrofit it onto everything at once.
None of this requires a new team or a new tool. It requires a decision about who has the final word, communicated to the teams that are affected.