Hotel PMS integration patterns — HTNG, APIs, and the operational stack
A modern hotel runs 15–30 specialized systems alongside the PMS. Making them all work together coherently is the most underappreciated technical work in hospitality.
What integrates with the PMS
The systems that integrate with the PMS at a typical full-service property: the central reservation system or channel manager (for inbound reservations), the loyalty platform (for member recognition and points), point-of-sale systems for each F&B outlet (for charge posting), the spa/golf/retail booking system (separate POS-like platforms), the access control system (for key encoding), the telephone call accounting system (for in-room phone billing — increasingly vestigial), the guest-Wi-Fi controller (for auth), and the payment processor (for tokenization and settlement).
Larger properties add more: casino management systems (player tracking and comp redemption), banquet event ordering (BEO and group billing), housekeeping management (room-status communication), guest-app platforms (mobile check-in, in-app concierge), and energy management systems (in-room thermostat scheduling based on occupancy). Each is its own integration project.
HTNG and standards
The Hotel Technology Next Generation organization publishes interface specifications for common hospitality integrations. Major specs include the single-guest-itinerary specification (folio data interchange), the express-checkout specification, and various specific-domain specifications for areas like spa, retail, and self-service kiosks. HTNG specs are useful as a baseline but are rarely implemented identically by two vendors — extensions and quirks are universal.
Vendors typically publish 'HTNG-compatible' interfaces that follow the spec broadly while adding fields and behaviors specific to their product. Integration projects discover this on first implementation: the spec gives you the skeleton, the vendor's documentation fills in the muscle.
Real-time vs. batch
Integration patterns split between real-time (synchronous API call with immediate response) and batch (queued messages exchanged on a schedule). Real-time is appropriate for guest-affecting data: a check-in needs to immediately update the access control system so the key card works at the guest's room. Batch is appropriate for accounting-side data: end-of-day F&B reconciliation, loyalty earning settlement.
Hybrid patterns are common. Real-time for the guest-experience concern, batch for the reconciliation concern, with the same underlying data crossing the integration twice on different cadences. The challenge is ensuring the two paths agree at the end of the day.
Failure modes
Integrations fail in predictable ways. Network issues take down a real-time channel; the receiving system stops getting updates. Schema drift — one side updates and the other doesn't — produces messages that fail validation. Authentication drift (expired API keys, rotated certificates) produces 401s across the interface. Each failure mode manifests differently but the root causes are structural.
Resilience patterns: queues between systems (messages buffer during outages and deliver when the remote comes back), circuit breakers (stop hammering a failing remote), and reconciliation jobs (periodically compare what should be in each system vs. what is). Properties that have implemented all three spend less time on integration incidents.
Operational ownership
Who owns integrations is an organizational question. Brand corporate IT owns integrations they specified (loyalty, CRS); property IT owns everything specific to the property (local POS, spa system, casino management). Specific vendor support agreements cover vendor-side issues; the property is responsible for noticing and escalating.
When a property uses a third-party management company, ownership shifts. The management company's IT team becomes the first-line responsible party, with brand corporate and vendors as second-line. The property GM's involvement is limited to operational impact rather than diagnosis and fix.