One API vs. five suppliers: the integration maths

The first supplier integration is a project. The fifth is a tax you pay every sprint, forever.

Why the cost curve is not linear

Teams estimate supplier integrations as if they were additive: six weeks each, so five suppliers is thirty weeks. The build is roughly additive. The maintenance is not.

Each supplier brings its own error taxonomy, its own idea of what a room is, its own timeout behaviour and its own habit of shipping a breaking change with a fortnight's notice. Now add the interactions: reconciling the same hotel arriving from three sources under three names, deciding which supplier wins on a tie, and working out what "partial availability" means when two of five suppliers timed out.

That is where the time goes. Not in the integration — in the mapping layer between them, which grows with the square of the supplier count rather than with the count itself.

The parts nobody estimates

Content deduplication. The same property from several wholesalers with different names, addresses, star ratings and photo sets. Getting this wrong means showing six near-identical results and losing the customer's trust.

Idempotency. A booking request that times out has either succeeded or not, and you cannot tell. Without an idempotency key on the supplier's side, your retry may create a second PNR. Some suppliers support this well. Some do not support it at all.

Post-booking events. Schedule changes and cancellations arrive by email, by a nightly file, by a webhook, or not at all depending on the supplier. Normalising that into one event stream is its own subsystem.

Settlement. Five suppliers means five statements, five sets of credit notes and five dispute processes. Finance will feel this before engineering does.

What an aggregation layer changes

You integrate one contract shape and absorb none of the churn. Suppliers joining, leaving, renaming fields or changing their timeout behaviour becomes someone else's on-call rotation. Your test suite has one set of fixtures. Your settlement has one counterparty.

The honest trade-off: you give up direct control over supplier selection and you take a dependency on someone else's uptime. Whether that is a good deal depends on whether wholesale contracting is actually your competitive advantage. For most OTAs, conversion is the advantage and supplier plumbing is overhead.

If you do integrate directly

Build the normalisation layer first, before the second supplier — retrofitting it across four live integrations is significantly worse. Insist on idempotency keys in the contract. And instrument fill rate per supplier from day one, because the supplier with the best rate sheet is often not the one that confirms.