Engineering · Aug 14, 2026 · 1 min
APIs as products
If a partner needs a meeting to integrate, the interface is unfinished. Contracts are the product.
Vantrea Tech
Internal APIs rot because they have captives. External APIs rot because nobody wanted to own versioning. Both need the same care: a contract, examples, and a deprecation policy written before the first breaking change.
Microservices are not the point. Boundaries are. Split a service when a team, a scale, or a change rate is different. Otherwise you have paid the distributed tax for a folder.
Errors are part of the interface. So are idempotency keys, pagination, and the way you name resources. These are product decisions. They do not belong only to the person who likes OpenAPI.
The best platform work we do is often a façade: a stable API in front of a vendor or a legacy core. That façade is the product. The thing behind it can be replaced later, which is the point.
Document the changelog. Someone is writing a client you will never see. Treat them as a user.
- api
- platform
- architecture