What is a unified travel API? One schema across flights, hotels and more

Why unify at the schema level?

Supplier integrations fail for two recurring reasons: every API looks different, and every API changes over time. Unifying at the schema level addresses both. Instead of teaching your systems how Amadeus, an airline NDC, a bedbank and a transfer network each work, you design once around a stable set of concepts — search, offer, order, traveller, payment, ancillary — and keep supplier‑specific rules at the edge.

For developers this means one SDK, one set of request/response models and one way of handling timeouts, retries, idempotency and webhooks. For the business it means faster time to ship new supply and a smaller blast radius when any one supplier shifts an enum, adds a mandatory field or changes a pagination rule.

Core objects: offers and orders

Every vertical in travel can be modelled as an offer that can become an order. A flight or a hotel room is returned as an offer with product, price, policy and availability. Once confirmed, that offer is captured as an order with references, documents and servicing actions. Unifying the offer and order model lets you search across channels, create one basket with multiple verticals and handle post‑booking changes with predictable idempotent calls.

In a unified API the nomenclature is consistent: an `Offer` has `items`, each `item` has `price`, `policies` and `fulfilment` requirements; an `Order` holds `travellers`, `payments`, `supplierReferences` and a `status`. An airline may talk about segments and fare families, a hotel about rooms and board types; the surface differs but the shape is the same.

Handling vertical differences without leaking complexity

Unification does not mean flattening everything to the lowest common denominator. A good schema preserves the important domain details per vertical behind a consistent facade. Flights need branded fares, seat maps and ancillaries; hotels need board types, policies and room‑level pricing; activities need timeslots and pickups. The API should expose those through typed fields while keeping the outer structure constant so clients can compose them.

Where a vertical has unique flows — e.g. airline ticketing versus hotel voucher issuance — the API should express them as operations on the same `Order` resource with predictable semantics: create, confirm, void, change, refund. Clients learn one mental model and handle special cases by capability flags instead of branching across suppliers.

Identity, idempotency and webhooks

Searches and bookings in travel are long‑lived and highly concurrent. A unified API should make correlation first‑class: stable request identifiers, idempotency keys for all write operations, and webhook events for order lifecycle changes. When a downstream system retries a payment or a client reconnects after a network split, the API returns the same order instead of duplicating work.

Webhooks are the glue for disruption and back‑office processes: order confirmed, ticket issued, schedule changed, refund completed. Because the event types are the same across suppliers, your mid‑office, CRM and analytics can subscribe once and stay in step.

Versioning and safe evolution

No schema should be static. Backwards‑compatible additions are inevitable as suppliers expose richer features. A unified API should publish an OpenAPI description, deprecate fields in place and version only when behaviour changes in a breaking way. Consumers upgrade deliberately, and the platform can run multiple mapping versions in parallel during migration windows.

The most important property is safety: a supplier change should not become your breaking change. That calls for strong validation, replayable test fixtures and an opinionated mapping layer that can absorb supplier drift without exposing it upstream.

Where Synapse fits

Synapse applies this model across nine travel verticals and multiple airline channels. It exposes one REST API described by an OpenAPI 3 schema, with JSON responses, webhooks for order events, per‑key rate limits and idempotency keys. Supply from GDS, NDC, LCC and bedbanks appears in one result set, and your negotiated contracts from Nexus sit beside them under the same rules.

Teams use Synapse on its own to power custom front ends, or alongside Elkanio products such as Nucleus for B2B portals. Either way, you integrate once against a stable schema and enable suppliers per market as your catalogue grows.

Who benefits from a unified API

Engineering teams who would otherwise maintain dozens of brittle connectors. Product teams who want to add a vertical or a supplier without a quarter of backend work. Operations teams who need consistent servicing and finance who want reconciliation to look the same across channels. A single schema aligns all of them.

Getting started

Start in a sandbox with your core use case: search, book and service one vertical end‑to‑end. Validate the webhooks into your mid‑office and CRM, and decide how you will represent travellers, orders and documents in your own system. When you are ready, enable live suppliers per market and expand to the next vertical without changing the client model you already wrote.