Unified API

A unified API abstracts supplier differences behind one set of concepts: offers that can become orders, travellers, payments, policies and fulfilment. Clients learn one schema and one set of behaviours, then enable suppliers and verticals without rewiring every screen.

Vertical specifics belong as typed fields, not bolted‑on blobs. Flights need fare brands, seat maps and ancillaries; hotels need board types and cancellation rules; activities need timeslots and pickups. Preserve those details while keeping the outer structure stable.

Reliability comes from opinionated mechanics: stable request identifiers, idempotency on every write, and webhooks for order lifecycle changes. When a client retries or reconnects, you return the same resource instead of duplicating work.

Evolution is deliberate. Additive changes ship without version bumps; behavioural changes create a new version that runs side‑by‑side until consumers migrate. Publish OpenAPI, mark deprecations in place, and test mapping changes against real traffic before rollout.

For operators, the value shows up in reduced connector maintenance, simpler mid‑office integration and faster time to add suppliers or markets. For developers, it is one SDK and one way to handle timeouts, retries and errors, independent of which airline or bedbank sits behind it.