How a channel manager connection works: messages, delays and errors

A channel manager connection is a two-way link between a hotel's own system and its sales channels: availability, rates and restrictions go out, and bookings, changes and cancellations come back. Each direction travels as separate messages, so the two sides can disagree for a while, and that gap is where delays and errors live.

A guest arrives with a confirmation for a room your front desk has already given to someone else. Neither system reports an error, and nobody changed anything by hand. The room was sold twice inside a gap between two messages. This article explains how a channel manager integration actually works: what travels in each direction, why change messages and full refreshes both exist, where delays come from, and which daily checks catch a silent failure before it becomes an overbooking.

What does a channel manager connection actually carry?#

It carries two short lists of facts in opposite directions: what you are selling, and what a guest has already bought.

Outbound, three kinds of fact travel. Availability is how many rooms of each room type are open for each date. Rates are the price for each room type and rate plan. Restrictions are rules such as minimum stay, closed to arrival, or stop-sell, meaning no sale at all. Inbound come new bookings, modifications such as new dates or a different room type, cancellations, and sometimes the guarantee or payment status attached to the booking.

Some things do not travel at all: photos, descriptions, policies, guest messages, invoices and the guest's bill. Those live in the channel's own extranet or in the hotel's system, and expecting them to sync is a common mistake. An interface, in plain words, is simply the agreed way two systems exchange these messages without a person typing.

The hotel's system holds the master copy of inventory. The channel holds the master copy of what it sold. Neither one is the master copy of both, which is exactly why the two must be compared. A message is small and specific: a date range, a room type, a rate plan, a number. It is not a copy of the hotel, and it does not describe why the number changed.

The connection is agreed per channel and per function. A channel may accept rates but not restrictions, or accept new bookings but not modifications, and the contract usually says so in a list rather than in a headline. For the division of duties between the systems on each side, see PMS, channel manager and booking engine: what each one does.

What is the difference between a one-way and a two-way connection?#

A one-way connection sends your availability and rates out; a two-way connection also brings bookings back into your system without anyone retyping them.

In practice, one-way means staff watch the channel's extranet and re-enter each booking by hand. Every hour between the booking and the retyping is an hour in which the same room can be sold again. Two-way means the booking arrives as a message, is matched to a room type and a rate plan, and appears in the reservations list with the channel's own booking reference attached.

Two-way is not one switch. It is a set of message types agreed per channel, and it can be partial: rates out, bookings in, but no modification messages. Two-way needs mapping before it needs anything else: the channel's room type and rate plan codes must be tied to yours, and the tie must be tested with real bookings, not with a single test rate. The mechanics of that mapping are covered in channel manager mapping: room types, rate plans and testing.

The question to ask a provider is not whether the connection is two-way but which message types it carries, and what happens to a message that is rejected. A partial connection is more dangerous than an honest one-way connection, because staff stop watching the extranet while the gaps remain.

Why do change messages and full refreshes both exist?#

A change message says what just changed; a full refresh says everything again, and the second one is what repairs a picture that has drifted.

A change message is small and fast: one rate, one date or one restriction changed, so one short message goes out. It is cheap to send and quick to apply. Its weakness is silence. If a change message is lost on the way, the other side keeps the old value, and nothing anywhere looks broken.

A full refresh sends the complete set of availability, rates and restrictions for a date range. It is slower and heavier, and it is the only thing that corrects accumulated drift. Channels limit how often and how much a hotel may send, so a full refresh after every price change would be wasteful and slow. But no delivery is perfect, and relying on change messages alone leaves a wrong price or an open date on sale for as long as nobody looks.

A workable rhythm is change messages as things change, plus a full refresh on a schedule and after any bulk edit such as a season change, a rate load or a closure. Order matters too: two changes to the same rate sent close together can arrive in the wrong order, and the next full refresh is what settles which one is true.

Where do delays come from, and why do they matter on the last room?#

A delay is the sum of small waits: the hotel's system queues the change, the channel manager batches it, the channel processes it, and the traveler's screen refreshes on its own schedule.

The chain has four hops: hotel system, channel manager, channel, and the traveler's search results. Each hop has its own queue and its own retry, and the waits add up. Many systems send in short windows rather than instantly, because the channel limits how many messages it accepts in a period. A failed send is usually retried automatically, which adds time rather than error: a retry that succeeds is invisible, and a retry that keeps failing is a message that never lands. A channel may also accept a message and apply it later, so acceptance is not the same as the change being visible to a traveler.

On the last room, a gap of minutes is enough. Two travelers search, both see one room, both book. The software did not oversell; the room was sold twice inside the gap. The wider causes are covered in hotel double bookings across channels: causes and prevention.

The practical rule: when a room type falls to its last room, close it on the channel by hand or accept the risk knowingly. Treating the system as a guarantee is not a policy. Write the rule down and give it an owner, because the decision is made at 23:00 by whoever is on shift.

What happens when a booking fails to arrive?#

The booking exists in the channel and not in the hotel's system, and the guest is real either way, so the hotel still owns the problem.

It shows up in one of two ways: the channel's report lists a reservation the hotel system does not have, or a guest arrives with a confirmation nobody at the desk recognizes. Duplicates usually come from impatience, not from software: someone re-enters a booking by hand before the message lands, and then the message lands too.

Common causes, in plain words: the rate plan was never mapped, the connection was paused for maintenance, a message was rejected because a field did not match, or the booking came from a channel the hotel believed was disconnected. For the general mechanics of system-to-system messaging, see hotel PMS integrations explained: APIs in plain words.

Who fixes it: the reservations manager reconciles and re-enters, then tells the channel what happened. The channel manager is a pipe; it does not know your guest and cannot call them. Before re-entering anything, check the channel's cancellation list, or you will re-enter a booking the guest already cancelled and hold a room nobody will use.

Record every case with the date, the channel, the booking reference, what was missing and what was done. Patterns appear in that record before they appear as an overbooking. And tell the guest what happened in plain words; do not blame the channel in front of them. The guest bought from the hotel, not from the pipe.

Which daily checks catch a silent failure?#

Three counts taken at the same time each day catch most silent failures: bookings, room nights and cancellations, per channel.

Count one is bookings per channel for yesterday, taken from the channel's own report. Count two is the same bookings as recorded by the channel manager, which is the middle of the pipe. Count three is the same bookings as they appear in the hotel's system. A mismatch is a finding even when every guest is fine. Investigate it the same day, not at check-in, because the next mismatch may not be harmless.

Beyond the counts, spot-check availability: pick two or three dates and compare what the channel shows with what the hotel system holds, including one date that should be closed. Check restrictions after any change, not only rates; a stop-sell that did not travel costs as much as a price that did not travel. Keep the counts in one place so a trend is visible: one mismatch is noise, three in a week is a connection problem with a cause.

What to do next#

Tomorrow morning, before the first check-in, take yesterday's three counts per channel and compare them. That single habit turns everything in this article into a routine: the two directions, the change messages and full refreshes, the delays on the last room, and the missing bookings all show up as a number that does not match. On our side, availability and rates flow from the hotel's system to the major OTAs through our Channex integration, now in pre-production testing, and we describe it that way because that is where it stands. If you want to see how that connection is built, you can request a briefing.