Thowfik Juhair

← All projects

Hotel supplier integrations: Juniper and TripMaker

Connected two hotel suppliers end to end, from search to cancellation, made booking safe when things go wrong, and took both integrations through the suppliers' certification.

2

suppliers certified for production

Juniper and TripMaker

926 ms → 15 ms

server freeze while reading a large supplier reply

Benchmark: 5 searches on a 1.3 MB response

13,073

TripMaker hotels added to the catalogue

Found by scanning 3.6 million supplier hotel IDs

The problem

Every hotel supplier has its own API, its own rules and its own way of reporting errors. A booking passes through several steps (search, price check, hold, book, cancel), and at each step something can change: the price can move, a request can time out, or the hotel can confirm late.

Getting any of these wrong means charging an agency the wrong amount, booking a room twice, or telling an agent a booking is confirmed when the hotel has not confirmed it.

What I did

  • Integrated the Juniper and TripMaker hotel APIs end to end: search, room availability, price check, booking, reading a booking back, and cancellation.
  • Took both through supplier certification: Juniper's 3 test combinations and TripMaker's 5 test cases were booked, read back and cancelled, including through the agency portal.
  • Rebuilt the Juniper, TripMaker and in-house contract integrations to one shared standard: if the price changes between search and booking, the agent is asked before anything is charged, and a booking the hotel has not confirmed is never shown as confirmed.
  • Made TripMaker booking and cancellation requests go out once, with no automatic retry, so a timeout cannot create a duplicate reservation.
  • Moved the reading of large supplier responses to background threads, and kept the supplier circuit breaker in Redis so a failing supplier is reported instead of showing “no hotels”.
  • Fixed multi-room bookings found in testing: one saved record, one confirmation number and one voucher line per room. One test stay of three rooms had been shown at $3,069 instead of $1,272.
  • Built the cancellation path (a live cancellation quote, penalties shown in the agency's currency, no cancellation after check-in) and the voucher PDF service.
  • Built TripMaker's catalogue import: a resumable scan of 3.6 million supplier hotel IDs to find the Saudi ones, then 13,073 hotels added to the catalogue.
  • Built much of the contract module for hotels Hala Saudi contracts directly: inventory, static and dynamic pricing, a municipality fee set by star rating, and two-person contract approval.

How a booking flows

Each step is in plain words. Open “Technical detail” for the engineering version.

  1. Search

    Ask each supplier for hotels and prices for the dates and guests the agent chose.

    Technical detail

    Supplier XML is parsed in a worker-thread pool so one large response cannot freeze the server. A circuit breaker kept in Redis, and shared by every server instance, stops calling a supplier that keeps failing.

  2. Check the price

    Before booking, confirm the price with the supplier. If it has changed, show the agent the new price and ask.

    Technical detail

    One price-change rule, shared by every supplier integration.

  3. Hold

    Hold the room and the agency's money while the booking completes.

    Technical detail

    Wallet funds are held with two-phase purchase locking; see the wallet case study.

  4. Book

    Send the booking once. If the outcome is unclear, read the booking back from the supplier instead of sending it again.

    Technical detail

    No automatic retry on book or cancel. Booking status changes are written compare-and-set, so two processes cannot overwrite each other.

  5. Confirm

    Show the booking as confirmed only once the hotel confirms, with one confirmation number for each room.

    Technical detail

    Per-room hotel confirmation numbers (HCN), synced on a schedule for bookings still waiting on the hotel.

  6. Cancel

    Get the cancellation cost from the supplier live, show any penalty in the agency's currency, and refund the right amount.

    Technical detail

    A cancellation quote that changes nothing, and cancellation blocked once the check-in date has arrived.

Results

  • Juniper and TripMaker both passed supplier certification and have production credentials.
  • One integration standard now covers Juniper, TripMaker and Hala Saudi's own contracted hotels.
  • Reading a large supplier response no longer freezes the server: the freeze fell from 926 ms to 15 ms in a benchmark.
  • 13,073 TripMaker hotels in Saudi Arabia were added to the catalogue.

Timeline

  1. Jun 2026Juniper search and booking integration built.
  2. Jul 2026Cancellation and refunds, per-room confirmation numbers, and Juniper certification work.
  3. Aug 2026TripMaker connected end to end and 13,073 hotels added; Juniper's static-data certification requirement completed.
  4. Sep 2026All three integrations rebuilt to one standard; certification re-run for Juniper and TripMaker.

What I learned

Retrying is not always safe. For a booking, sending a request twice can mean two reservations, so the safer choice is to send once and then check.

Multi-room bookings expose problems a single room never shows. The case with the most moving parts is the one worth testing first.

Words on this page

API
The agreed way two computer systems talk to each other.
Certification
A supplier's own test of an integration, run on real booking cases before they grant production access.
Circuit breaker
A switch that stops calling a supplier that keeps failing and reports it, instead of making every search wait.
Compare-and-set
Saving a change only if nothing else has changed the record since it was read.
Worker thread
A separate lane for heavy work, so the main server keeps answering requests.
HCN
Hotel confirmation number: the hotel's own reference for a booked room.

Built with

NestJSTypeScriptPostgreSQLPrismaRedisNode.js worker threads