Supplier adapters and data normalisation
Supplier APIs were built at different times for different buyers. Some still exchange SOAP/XML messages, newer ones use REST with JSON, and airline content comes through GDS interfaces such as Amadeus and Galileo or through IATA's New Distribution Capability (NDC) standard. Each one names rooms, board types, taxes and cancellation terms differently.
The platform connects every supplier through a dedicated adapter. The adapter handles that supplier's authentication, request format, error codes and rate limits, and converts its responses into one internal schema. Everything above that layer, including the search results page, the pricing engine, the voucher template and the accounting export, works only with the normalised data. That separation is why a new supplier can be added without redesigning the booking flow, and why a supplier changing its API version affects one adapter rather than the whole system.
Hotel mapping: one property, one result
Connect five bed banks and the same Dubai hotel may arrive five times, with slightly different names, addresses and coordinates. Showing all five confuses customers and hides the real price comparison. Dynamic hotel mapping matches those records to a single master property so the customer sees one hotel with the best available offer, while the system still knows which supplier each rate came from. For larger inventories the platform can also use third-party mapping services such as GIATA and Vervotech.
Search, timeouts and slow suppliers
A single hotel search fans out to every supplier covering that destination at the same time. Suppliers do not all answer at the same speed, and one slow or failing connection should not hold up the page. Responses are collected within a time window, results from suppliers that answer are shown, and a supplier that times out is skipped for that search rather than breaking it. Static content such as hotel descriptions, images and facilities is stored locally, while rates and availability are always requested live, because those change by the minute.
Supplier-side limits matter here too. Most bed banks cap the number of queries per second each client can send, and exceeding it gets requests throttled or blocked. The platform controls outbound request volume per supplier so peak-hour traffic on your site does not trip those limits. Our guide to QPS limits in hotel API integration covers this in more detail.
Rate recheck before confirmation
Search results are a snapshot. Between the moment a customer sees a price and the moment they pay, the supplier may have sold the last room or changed the rate. Before taking payment, the system runs a PreBook call that rechecks the exact room, rate and cancellation policy with the supplier. If anything has changed, the customer sees the new terms before confirming. This one step prevents most of the disputes that come from "the price changed after I paid".
Booking, payment and supplier settlement
On confirmation, the booking is created with the supplier and stored with its supplier reference, your internal reference, the net cost, the sell price and the policy that applied. Customer payment runs through the payment gateway you choose, such as Stripe, CCAvenue, Telr or Network International, while sub-agents can book against a credit limit. On the supply side, suppliers that accept card payment can be paid with virtual credit cards generated per booking, which keeps supplier payments traceable to individual reservations.