Most API tooling assumes one repository, one specification. But your architecture doesn't work that way.

In our previous article , we explored how Barbacane eliminates configuration drift by compiling your OpenAPI spec directly into the gateway's runtime artifact. One spec, one .bca file, zero drift.

But what happens when your architecture has more than one spec?

The Multi-Spec Reality

In a typical microservices setup, your API surface isn't described by a single file. Whether you're working contract-first or generating specs from code, you end up with multiple specifications:

A User Service with its own openapi.yaml

An Order Service with its own openapi.yaml

An Inventory Service exposing both REST endpoints and event consumers, described across OpenAPI and AsyncAPI files

Event schemas scattered across repos

Each file is validated in isolation, deployed independently, and versioned on its own timeline.…