Channel Manager Architecture: Booking, Expedia, MakeMyTrip Integration
Hotels distribute inventory across many channels, Booking.com, Expedia, MakeMyTrip, Agoda, GDS, their own site. Channel managers keep all these in sync. Here's the working architecture.
Key takeaways
- Two-way sync: hotel PMS ↔ channel manager ↔ each OTA.
- Idempotent operations are essential; retries are constant.
- Rate parity rules must be enforced explicitly.
- Real-time vs near-real-time depends on revenue criticality.
- Failure modes (oversold, missed bookings) are operationally painful.
The system
Hotel PMS
Owns the source of truth: rooms, rates, availability, bookings.
Channel manager
Mediates. Receives updates from PMS; pushes to OTAs. Receives bookings from OTAs; pushes to PMS.
OTAs
Display inventory, capture bookings.
The flows
Inventory push
PMS → Channel manager → each OTA. New rates, availability changes, restrictions.
Booking pull
OTA → Channel manager → PMS. New bookings, cancellations, modifications.
Rate parity check
Channel manager validates rates across all channels match (within agreed rules).
Integration patterns
Each OTA different
Booking.com: XML API or 2-way XML. Expedia: EQC or EQC-XML. MakeMyTrip: their own. Agoda: their own.
No standard. Each OTA's quirks must be modeled.
Sync frequency
Inventory: real-time or near-real-time (every minute). Bookings: pull frequently (every 1-5 minutes).
Idempotency
Every operation must be safe to retry. OTAs and PMS occasionally fail; retries are constant.
Conflict resolution
If two systems disagree (PMS says 5 rooms; OTA says 4 sold), resolve. Usually PMS wins; alert for human review.
Operational concerns
Oversold
PMS sells 1 room; OTA sells the same room independently. Channel manager misses the conflict for a few minutes.
Mitigation: aggressive sync, buffer inventory at OTAs, manual handling when oversold happens.
Missed bookings
OTA confirms booking; channel manager fails to push to PMS. Hotel doesn't know.
Mitigation: persistent queue, retry forever, alert on stuck bookings.
Rate parity violation
OTA shows lower rate than direct (due to OTA's own discount). Direct customers angry.
Mitigation: monitor rates across channels; raise alerts on parity violations.
Architecture patterns
Event-sourced
Every change is an event. Queues route to interested systems. Audit trail by default.
Connector per OTA
Each OTA integration is a separate module. Doesn't break others when one OTA's API changes.
Reconciliation jobs
Daily compare booking records across PMS and each OTA. Discrepancies surface.
Common pitfalls
Sync API in critical path. OTA latency blocks PMS.
No idempotency. Duplicate bookings.
Single thread per OTA. Doesn't scale.
No reconciliation. Discrepancies compound.
What we recommend
Event-sourced architecture. Connector-per-OTA. Aggressive reconciliation. Buffer inventory. Operational playbooks for oversold.
FAQs
Build vs buy? SiteMinder, RateGain, custom, most hotels buy.
API documentation? OTAs require partner agreement to access.
Real-time vs batch? Real-time for inventory; near-real for bookings.