Hotel PMS integrations explained: APIs in plain words

A hotel PMS integration is an agreed connection that lets two systems exchange specific data automatically. An API (application programming interface) is the counter where one system asks and another answers. What matters is who asks, who is told, what happens when a message fails, and who fixes it.

A rate is changed at the front desk at nine in the morning. By the afternoon the hotel's own website, a travel agency and a sales channel show three different prices, and nobody typed anything wrong. The gap is not in the people; it is in the connections between the systems they use. After reading this article you will be able to judge those connections without reading a single line of code, using four questions that work in any meeting with a software provider.

What is a hotel PMS integration, in plain words?#

An integration is an agreed, limited connection that lets one system pass specific data to another without a person retyping it. The API is the counter where the request is made and the answer comes back.

Start with the PMS itself: the property management system holds reservations, rooms, guest bills and room status. The hotel technology network of the American Hotel & Lodging Association, HTNG, states that for hotels the PMS serves as the primary interface for guests, reservations, folio and room data (AHLA / HTNG, "HTNG Completed Workgroups", 2026-11 (opens in a new tab)). Everything else in a hotel's technology stack connects to it, which is why its integrations deserve the owner's attention and not only the IT person's.

The API is a fixed list of questions a system is allowed to ask and the answers it gets back. Picture a front desk counter: you can ask for a room, a bill or a key, and you cannot walk into the back office and move the furniture. The counter limits what can be asked, in what form, and what comes back.

The integration is the working arrangement around that counter: what is asked, how often, in what form, and who is responsible when the answer is wrong. An API without that arrangement is a door with nobody behind it. The same AHLA / HTNG source notes that hotel system integrations are generally lengthy and complex, especially integrations with the PMS. Treat an integration as a project with an owner and a start and end date, not as a switch that is flipped once.

Every integration also carries a direction. Some data flows into the PMS, such as a reservation arriving from a channel; some flows out, such as rates and availability; some flows both ways. Ask which direction applies before you discuss anything else, because direction decides who depends on whom.

If you are also weighing a broader platform change, the same questions apply when comparing a hotel operating system with a PMS: the more systems one platform replaces, the fewer counters there are to govern.

Asking versus being told: what is the difference between polling and change messages?#

In a regular check, called polling, one system asks the other every few minutes whether anything changed. In a change message, called an event, the system that changed tells the others straight away.

Polling is simple and predictable: the asking system repeats the same question on a fixed interval. Its weakness is that the interval sets the worst-case delay, and it keeps asking even when nothing has changed. That is usually an acceptable price for simplicity.

Change messages work by subscription. HTNG's Event Notification Specification (version 3.0, 24 April 2015) sets out a publish-and-subscribe method so that hotel systems exchange data automatically when key events occur, such as guest check-in, guest check-out or a room going out of service: a system subscribes to the events it needs, and the source system notifies it when they happen (AHLA / HTNG, 2015-04-24 (opens in a new tab)).

The trade-off is about who carries the risk. Events are faster but assume the receiving system is reachable; if it is down, the message has to be kept and replayed. Polling assumes the asking system keeps asking, and it will notice nothing in between.

For example: a room is taken out of service at 07:00. With an event, the channel manager hears within seconds. With a fifteen-minute poll, it hears up to fifteen minutes later, and a guest can book that room in the gap.

What the worst-case delay actually means#

Neither method is better in the abstract. Ask which method a provider uses for which data, and what the worst-case delay is for a rate change, a reservation and a room status change. Those three answers are often different, because reservations may arrive as events while rates go out on a poll.

A provider that answers "real time" has not answered. Real time is not a number; the worst-case delay is.

Why do copies of the same rate drift apart?#

Because more than one system is allowed to be the authority for the same number, and each copy is refreshed on its own schedule.

The source of truth is the one place where a value is edited; everywhere else holds a copy that is refreshed from it. The concept is simple, and most hotels have never written down which system holds it for which data.

Drift has four common causes: a value edited in two systems, a manual override at the front desk that never reaches the other side, a message that failed and was never replayed, and a person correcting one copy by hand. Each one is quiet. A lost reservation shows up as an angry guest at the desk; a stale rate shows up only when someone books at yesterday's price.

The rule that prevents most of it: one authority per data type. Room status and the guest bill belong to the PMS. The published sell price belongs to one system only, and every other system reads it rather than editing it.

Copies are not the problem; unnamed copies are. If a copy exists, it needs a refresh rule and a visible timestamp, so a person can see how old the number on the screen is. A practical audit: for rates, availability, guest identity data and outlet charges, ask "where is this edited?" If two answers come back for the same item, you have found a drift source before it costs you a booking. For a wider view of how these systems relate, see how the core hotel systems fit together.

What happens when a message fails?#

A failed message is normal. What separates a good integration from a bad one is whether anyone finds out, how the message is replayed, and who owns the fix.

Retries are the first line: the sending system tries again on a schedule. The danger is a system that retries forever and tells nobody, so the failure looks like silence rather than an error. Silence is the failure mode to fear most.

Alerts are the second line. A failure has to reach a person, not a log file. Ask where the alert goes, who reads it, and what that person does at 23:00 on a Saturday.

Daily reconciliation is the third line. Once a day, compare counts and totals between the two systems: reservations created on each side, charges posted to guest bills against the outlet's own record, identity notifications prepared against arrivals. Differences are investigated the same day, not at month end, because a difference found the same day is a correction and a difference found at month end is a dispute.

Replay matters as much as alerting. Ask whether a failed message can be sent again without creating a duplicate, because a duplicate reservation is often worse than a missing one. And write the failure path down before go-live: a one-page sheet with the four answers is worth more than a long contract appendix nobody opens.

How do versions and scoped access protect an integration?#

A version is a fixed edition of the counter's rules, so one side can change without breaking the other. Scoped access means each connection may only do the specific things it was granted.

Versions work like this: when a system changes how it answers, it publishes a new version and keeps the old one running for a period. Ask how long old versions stay supported and how you are told before one is retired, because a retirement date is a deadline for your provider, not for you.

Scoped access, in plain words, is a key that opens two doors, not the building. The IETF standard OAuth 2.0 (RFC 6749, October 2012) lets a third-party application obtain limited access to a web service, either on behalf of the resource owner after an approval step or on its own behalf, and lets the application state the scope of the access it asks for (IETF / RFC Editor, "RFC 6749", 2012-10 (opens in a new tab)). Least privilege in hotel terms: a channel manager needs rates and availability, not guest bills. An e-document integrator needs invoice data, not the whole guest history. If a connection asks for more than its job requires, ask why in writing.

Two further checks. Signed messages let the receiving system verify that a message really came from the sender and was not altered on the way; you do not need the mechanics, you need to know whether it is done. And revocation: ask how access is withdrawn when a contract ends, a provider changes, or a staff member with access leaves. An access that cannot be withdrawn quickly is a standing risk.

The cleanest arrangements define each action once and serve it to every system that needs it, rather than rebuilding the same rule per connection. The same idea underpins hotel software architecture for AI: one definition, many doors.

Which integrations does every hotel in Türkiye deal with?#

Four, in practice: the channel manager, the e-document integrator, the guest identity notification (KBS) and the central tourism database. Each one carries a different kind of data and fails in a different way.

The baseline is that in Türkiye every stay involves a payment, a fiscal document (an invoice or e-document), a guest identity notification (KBS) and personal data (KVKK, the personal data protection law). Any integration you buy sits somewhere on that path.

The channel manager carries rates and availability to the sales channels. The questions are which system is the authority for the price and what the worst-case delay is, not how many channels are listed. The e-document integrator is a licensed party that issues e-Fatura and e-Arşiv (electronic invoices): the hotel's system prepares the document, a person reviews it, the integrator issues it. Human review before sending is good practice, and it is also the last place a wrong amount can be caught.

KBS, the guest identity notification, is prepared and sent from the check-in flow. The technical rules around it are not publicly settled in the sources available here, so confirm the details with your provider rather than relying on a forum post.

The central tourism database is the newest obligation. Ministry circular 2026/1 (16.04.2026) obliges accommodation facilities and their software providers to send data to the central tourism database through a web-service API, according to alomaliye.com (6 May 2026) and a TGA General Manager statement in Dünya (18 May 2026). Those reports describe the cadence as daily where the flow is automatic and monthly by the 15th where it is manual. Confirm the cadence, the scope and your own case against the circular text and with your provider. No sanction is stated in the sources read here.

Automatic feed or manual entry#

An automatic feed sends data from your system on a schedule; manual entry means a person types it into a portal. Manual entry works until that person is on leave, and then the gap is invisible until someone asks for the record.

If the roles of these systems are not yet clear in your head, start with PMS vs channel manager vs booking engine.

Built, tested or live: what should you ask before you trust an integration claim?#

Ask for the three states separately, because "we integrate with them" can mean anything from a design document to a connection running in a hotel today.

Built means the code exists and works in a test environment. This is real work, and it is not the same as a working connection. Tested means it has been run against the other side's own test environment, with the message shapes that side actually sends, not only the provider's own sample data. Ask which environment, and who on the other side confirmed it. Live means it is running for at least one real property, with a named person who can confirm it and describe what happens when it fails. Ask for that name, and ask what the failure looked like the last time.

The seven questions worth carrying into every meeting: which direction does data flow, which system is the authority, what is the worst-case delay, where do alerts go, who fixes a failure, how is access withdrawn, and how long are old versions supported.

A provider that separates these three states honestly is easier to work with than one that claims everything at once, because you know exactly what you are buying and when.

What to do next#

Pick the one integration that would hurt most if it failed silently, write down its four answers, who asks, who is told, what happens when a message fails, who fixes it, and take that page to your provider. The parts of this article fit together in that order: the counter explains what an API is, polling and events explain the delay, the source of truth explains the drift, and the failure path explains why an integration is a responsibility before it is a feature.