API integration in hospitality: connecting PMS, POS and the guest technology ecosystem

The hospitality technology stack

Most hotels operate with a layered set of systems that have accumulated over time – some chosen deliberately, some inherited, some imposed by brand standards. At any given property you might find a Property Management System (PMS) handling reservations and room assignments, a Point of Sale (POS) system covering the restaurant and bar, a channel manager connecting rates to online travel agents, a loyalty platform managing guest profiles and a guest-facing app for everything from check-in to in-room dining.

Each of these systems generates data. Each has its own data model, its own vendor and its own release cycle. The challenge isn't making any one of them work – it's making them work together. That's where API integration comes in, and where most of the complexity in hospitality technology actually lives.

The good news is that the industry has made genuine progress here. Modern cloud-based platforms like Mews, Cloudbeds and Apaleo were built with open APIs from the ground up, which makes integration considerably more straightforward than working with older on-premise systems like Opera (though Opera Cloud has improved significantly). The bad news is that many properties are still running a mix of old and new, and the integration burden falls on whoever is trying to connect them.

Why the PMS is the integration hub

The Property Management System is the operational core of a hotel. It holds the guest record, the reservation, the room assignment and the folio – the running tab of everything a guest has been charged during their stay. Because it owns the guest record and the folio, almost every other system in the stack needs to talk to it.

The POS needs to post F&B charges to the correct room folio. The channel manager needs to pull availability and push confirmed bookings. The loyalty platform needs to read guest profiles and post points. The guest app needs to trigger check-in, request room assignments and potentially communicate with door lock systems. The payment gateway needs to tokenise card details that the PMS can later use to settle the account.

This hub-and-spoke model means the quality of the PMS's API has an outsized effect on everything else. A PMS with a well-documented, stable REST API – like Apaleo or the newer Mews APIs – makes integration work tractable. A PMS that exposes only a legacy HTNG or FIAS interface, or that requires custom middleware to translate between its internal data model and anything modern, multiplies the complexity of every integration you try to build on top of it.

PMS to POS: the core operational integration

The integration between the Property Management System and the Point of Sale system is the one that causes the most day-to-day operational pain when it breaks. A guest orders a bottle of wine at dinner and expects it to appear on their room bill at checkout. That sounds simple. The underlying mechanics are not.

When a server posts a charge to a room, the POS needs to verify that the room number exists, that the guest has authorised room charges, and that the folio is open. It then needs to send the transaction – line items, amounts, VAT breakdown – to the PMS in a format the PMS will accept, and receive confirmation that the charge has landed correctly. If anything in that chain fails silently, the charge doesn't appear on the folio, a guest checks out without paying for it, and someone notices at month-end reconciliation.

The traditional integration method was a direct database-level or socket connection between the POS and PMS – brittle, difficult to monitor and frequently broken by system updates on either side. Modern integrations use documented APIs and middleware that can handle retries, log failures and alert operations teams when transactions don't confirm. The shift matters enormously for reliability.

Common POS systems in hospitality – including Oracle MICROS, Lightspeed and Tevalis – all have PMS integration capabilities, but the depth of that integration and the reliability of specific PMS pairings varies considerably. Before choosing either system, it's worth mapping out which pairings are genuinely certified and which are theoretical.

Channel managers and OTAs

A channel manager sits between the PMS and the online travel agents (OTAs) – Booking.com, Expedia, Airbnb and the rest. Its job is to maintain a consistent, real-time view of availability and rates across every distribution channel, and to push confirmed reservations back into the PMS.

The core integration is two-directional. The channel manager pulls current inventory and rate plans from the PMS and pushes them out to each connected OTA. When a booking comes in through any channel, the channel manager receives it, deducts availability from all other channels to prevent double-booking, and creates a reservation in the PMS. This needs to happen quickly – availability windows can be seconds in peak booking periods.

Channel managers like SiteMinder and RateGain connect to OTAs using the OTA_HotelAvailNotif and OTA_HotelResNotif message schemas from the OpenTravel Alliance, or via proprietary APIs depending on the OTA. The PMS connection typically uses the channel manager's own API or a middleware layer. Every link in this chain is a potential point of failure, and rate parity errors – where different OTAs show different prices for the same room – are frequently a symptom of an integration problem rather than a configuration one.

Loyalty programmes and CRM

Loyalty integration is where data quality problems become most visible. A guest who is a member of your loyalty programme expects to be recognised at check-in, to have their preferences noted and to see their points balance updated after their stay. Delivering that requires the PMS and the CRM or loyalty platform to share a consistent guest profile – and that's harder than it sounds.

Guest profiles accumulate across bookings made through different channels, under slightly different name formats, with different email addresses. The PMS may hold one version of a profile and the loyalty platform another. Without a reliable matching mechanism – typically built around a loyalty membership number or a verified email address – profiles fragment, points don't post correctly and the personalisation that loyalty is supposed to deliver never materialises.

The integration points required are: profile synchronisation between PMS and CRM at booking and check-in, points posting from the PMS to the loyalty platform at checkout, and the ability for the loyalty platform to push member status and preferences back to the PMS before arrival. Each of these requires reliable two-way API connectivity and a well-defined data mapping between the two systems' guest record structures.

For hotel groups operating across multiple properties, the challenge scales – a guest should be recognised regardless of which property they stay at, which means the loyalty platform needs to aggregate data from multiple PMS instances, each of which may be running different versions of the same software or different software entirely.

Guest experience apps and mobile check-in

Guest-facing apps have become a meaningful part of the hospitality stack – pre-arrival check-in, mobile keys, in-room dining orders, upsell requests, messaging with the front desk. Each feature requires API connectivity to a different backend system.

Mobile check-in requires the app to read the reservation from the PMS, collect any required information (passport details, payment confirmation), update the reservation status and – if the property uses mobile keys – communicate with the door lock management system to issue a digital key. Door lock platforms from ASSA ABLOY, Dormakaba and SALTO each have their own APIs and credential formats. The app integration needs to handle all of them, or the property needs to standardise on a single lock platform.

In-room dining orders placed through an app typically route to the POS kitchen display system and post charges to the PMS folio. That's the same PMS-to-POS integration discussed earlier, triggered from a different entry point. Upsell requests – early check-in, room upgrades, additional amenities – require the app to check availability in the PMS and either book automatically or trigger a workflow for front-desk approval.

The challenge with guest apps is that they aggregate integrations that, in isolation, each have their own failure modes. An app that promises a seamless experience needs all of its underlying integrations to be reliably operational simultaneously. That's a meaningful engineering and monitoring commitment.

Payment systems and PCI DSS compliance

Payment handling in hospitality has additional complexity because card details are captured at booking (often weeks before arrival) and charged at checkout – sometimes with incremental charges for incidentals in between. This means the PMS needs to store a payment credential for the duration of the stay without actually holding raw card data, which would bring the entire PMS environment into full PCI DSS scope.

The standard approach is tokenisation. The payment gateway captures the card at booking and returns a token – a reference that can be used to initiate future charges but has no value outside the payment processor's system. The PMS stores the token rather than the card number. When checkout comes, the PMS passes the token to the gateway to settle the folio. This approach, implemented correctly, limits the PCI DSS scope of the PMS significantly.

The complication arises at integration boundaries. If the POS, the PMS and the payment gateway are from different vendors, the tokenisation needs to be consistent across all of them – a token issued by the gateway needs to be usable by both the PMS and the POS when charging the same guest. Not all gateway and PMS combinations support this cleanly. Scoping and segmentation decisions made during integration design have real compliance implications, and it's worth involving a qualified security assessor early rather than retrospectively.

Where hospitality integrations typically go wrong

The failure modes in hospitality integrations are consistent enough to be worth naming directly.

Point-to-point integrations that break on updates. A direct connection between two systems – hardcoded to specific API versions or database schemas – breaks the moment either vendor releases an update. Without a middleware or abstraction layer, every system update becomes a potential integration incident. The fix is to build integrations against stable, versioned APIs and to maintain a clear dependency map so you know what to test when anything changes.

No error monitoring. Many hospitality integrations run silently in the background. When they fail, nothing alerts anyone – charges don't post, bookings don't sync, profiles don't update. The failure only surfaces when a guest complains or a reconciliation shows a discrepancy. Integrations need active monitoring with alerting on failed transactions, not just passive logging.

Data mapping mismatches. Different systems use different field names, date formats, currency representations and identifier schemes for the same underlying concepts. A reservation in the PMS is identified by a confirmation number; the same reservation in the channel manager is identified by the OTA booking reference. A guest in the PMS has a profile ID; the same guest in the loyalty platform has a membership number. These mappings need to be explicitly defined, documented and tested – not assumed to work because both systems have a "guest name" field.

Assuming the vendor handles it. Vendors will often say their system "integrates with" another system. That's rarely the full picture. Integration depth, reliability and support vary significantly between certified integrations and theoretical ones. Before committing to a technology stack, get specific about which version of the API is supported, what the testing and certification process looks like and who owns the integration when something breaks.