From the outside, a travel booking site is a search box, a list of results and a confirm button. Three screens. A weekend project, surely.
The screens are the small part. The real product is everything behind them: a dozen suppliers, each with its own idea of what a "room" or a "fare" is, each with its own quirks, and each capable of going down at exactly the wrong moment. Most of the engineering in travel software is about making all of that feel like one calm, dependable service.
Suppliers don't agree on anything
Ask three suppliers for the same hotel and you'll get three different names for it, three different ways of describing a cancellation policy, and prices that may or may not include tax depending on the day. One returns everything in a single response. Another makes you call five endpoints in order. One documents its errors carefully; another returns a cheerful 200 OK with a failure buried in the body.
The first job is normalisation: translate every supplier into one internal shape, so the rest of your platform never has to care who a price came from. It's tedious, and it's the single most valuable piece of code in the system.
Slow is the same as broken
A customer waiting on search results doesn't care that the supplier is having a bad afternoon. A few habits make the difference between a slow site and a resilient one:
- Strict timeouts. Decide how long you'll wait for each supplier, and stop. Show what you have.
- Parallel calls. Ask everyone at once, and don't let the slowest one hold up the rest.
- Sensible caching. Cache what changes slowly (content, photos, descriptions) for a long time, and what changes fast (price, availability) for a very short one.
- Graceful degradation. If one supplier fails, results from the others still appear.
The booking step is where it gets serious
Search can be forgiving. Booking can't. Someone is about to pay real money, and the worst outcomes are the quiet ones: charged twice, charged with no booking, or a booking with no record on your side.
That means recording every step (request, response, payment, confirmation) so any booking can be traced from start to finish, and building a clear path for the awkward cases: payment taken but supplier unconfirmed, supplier confirmed but your system didn't hear back. These cases will happen. The only question is whether you planned for them.
You can't fix what you can't see
Suppliers degrade slowly and unevenly. A connection that's fine in the morning may be timing out by evening. Good monitoring tracks the boring numbers per supplier (response time, error rate, how often a search returns nothing) and alerts a human before customers notice. A simple dashboard showing "supplier X has been slow for twenty minutes" is worth more than most features.
What this means if you're commissioning a build
- Ask how the team handles a supplier being down. If the answer is vague, keep asking.
- Expect the integration work to be a large share of the effort and budget, and be wary of quotes that treat it as an afterthought.
- Insist on logs and booking traceability from day one. It's much cheaper than adding it after the first incident.
- Start with the few suppliers that matter most, and make those solid before adding more.
None of this is glamorous, and none of it shows up in a screenshot. But it's the difference between a booking site that looks good in a demo and one you can trust with a customer's holiday.
Reliable integrations are the foundation for almost every automation worth having. If you're deciding where to start, our practical guide to automating with a CRM and AI shows how to pick the first jobs, and our API and integration services and travel technology pages describe what we build. Hotels face a very similar challenge with channel connections, which we cover in what a hotel PMS should do on a busy Sunday.
