Skip to main content
HolixoraHOLIXORA
← Back to Blog

Technology

Why We Build API-First: The Integration Architecture Behind Holixora Products

Holixora2026-07-232 min read

Every Holixora product is built API-first. This means the API is designed and built before the user interface, and the UI is a client of the API rather than a layer that talks directly to the database. It is a design philosophy with concrete architectural consequences.

The immediate reason for this choice was practical: building multiple products that need to share data and trigger each other requires well-defined interfaces between them. If Mercora inventory data is going to feed the Credit System risk model, there needs to be a documented, stable API between them.

What API-First Enables for Customers

The less obvious benefit of API-first design is what it enables for customers who want to build their own integrations. A retailer who wants to push Mercora sales data into their own business intelligence tool can do that. A hotel group that wants to pull Hanoman occupancy data into a custom dashboard can do that.

These integrations are possible because the API exists as a first-class product, not as an afterthought layer built to support a specific integration request.

The Documentation Obligation

API-first design creates an obligation to maintain good documentation. An undocumented API is only marginally better than no API for external developers. Keeping API documentation current, accurate, and complete is engineering work that is easy to deprioritize.

We treat API documentation as part of the definition of done for any API change. A feature that adds or modifies an endpoint is not complete until the documentation reflects the change.

The Versioning Problem

As products evolve, APIs change. Breaking changes to an API break every integration built on it. API versioning is the standard solution, but it creates maintenance overhead — multiple API versions running simultaneously, each needing to be supported until integrations migrate.

Our approach is to prefer additive changes over breaking changes wherever possible, version major breaking changes with migration guides, and deprecate old versions with explicit timelines that give integration builders time to update.