XML connections with tour operators and bedbanks: what a hotel agrees to
An XML connection automates data exchange between your hotel and partners. This guide explains what travels in each direction, how to test mappings, and when to stop manual loading.
Contents
Key takeaways
- An XML connection replaces retyping with a scheduled exchange: availability, rates and restrictions go out, bookings, changes and cancellations come back.
- Push and pull describe who speaks first, not who is in charge: the hotel's system pushing updates, or the partner pulling the current picture when a traveler searches.
- A connection carries only what the hotel has mapped and loaded, so an unmapped room type or rate plan is a booking that cannot arrive.
- When a booking fails, each side holds half the story, which is why the agreement must name who watches the connection and who fixes a gap.
- Switching off manual loading is a decision about trust in the mapping and the reconciliation habit, not about the format of the data.
A hotel XML integration is an automatic data exchange between a hotel's system and a tour operator or bedbank: the hotel sends availability, rates and restrictions, and the partner sends bookings back. The hotel agrees to keep that data accurate, to accept bookings that arrive through it, and to test the mapping before it goes live.
The email says the tour operator will connect by XML and asks for your details by Friday. Nobody in the room can say what will actually travel over that connection, or who is responsible when a booking does not arrive. After reading this article you will be able to name what travels in each direction, ask the partner the questions that settle push and pull, and decide when it is safe to stop loading rates by hand.
What is a hotel XML integration?
It is an automatic exchange of structured data between the hotel's reservation system and a partner's system, so that neither side retypes the other's information.
XML is a way of labelling data so that two systems read the same field the same way. The label matters less than the agreement on meaning: a double room on the hotel side must be the same double room on the partner side. Outbound, the hotel sends availability by date and room type, prices by rate plan, and restrictions such as minimum stay, closed to arrival and stop sale. Inbound, the partner sends new bookings, changes and cancellations, each carrying a reference the hotel can match to its own record.
The exchange runs between systems, not people: no email, no portal login, no retyping. The hotel's own system stays the record its team works from. What the hotel actually agrees to is a duty, not a format: keep the data current, accept what arrives through the connection, and reconcile it against the property's own records.
One commercial point sits behind the technical one. A bedbank may resell onward, so the agency name on a booking is not always the name on the contract. Ask who is entitled to sell your rooms and at which rate. The connection itself decides nothing. It carries what the hotel has already decided and loaded.
| Direction | What travels | Example | What goes wrong when it is wrong |
|---|---|---|---|
| Outbound, availability | Rooms open or closed by date and room type | A room left open after a direct sale | A double sale |
| Outbound, rates | Price per rate plan and date range | A stale price reaching a guest | A price dispute |
| Outbound, restrictions | Minimum stay, closed to arrival, stop sale | A stop sale that never left the hotel | Rooms sold you meant to close |
| Inbound, bookings | A new reservation with the partner's reference | A booking the hotel cannot match | A guest with no room |
| Inbound, changes and cancellations | A shortened stay or a cancelled room | A cancelled room still held | Inventory lost to a ghost booking |
Push and pull: who starts the conversation?
Push means the hotel's system sends an update when something changes. Pull means the partner asks for the current picture at the moment a traveler searches.
A push is triggered by an event, such as a booking, a closure or a price edit, or by a fixed schedule. It needs a retry when the partner's system is unavailable, and a screen that shows whether the last update landed. A pull is a question asked and answered inside the partner's time limit. If the hotel's system answers slowly, the search shows nothing or falls back to an older picture.
Most connections use both: push for the working picture through the day, pull for the last check before a traveler books. The gap between the two is where double sales live. For example, a room sold at the front desk at 14:02 and pushed at 14:05 leaves a three-minute window in which the partner still believes the room is free.
Ask the partner which mode it uses, how often it pushes or pulls, what its timeout is, and what happens to an update that fails. Push and pull describe who speaks first. They say nothing about which side is right when the two pictures disagree, which is why the reconciliation routine matters more than the mode. For what happens inside the messages themselves, delays and error handling, see how a channel manager connection works.
TipThree questions that settle most push and pull arguments
Which events trigger a push, how long a pull may take before the partner gives up, and where the last successful update is visible to both sides.
How do contract rates and dynamic rates travel over a connection?
A contracted rate travels as a rate plan: a named price for a named room type, board type and date range, with its cancellation and stay rules attached. A dynamic rate travels as a rule the partner can apply, or as a price the hotel keeps sending.
Contract loading means dates, room type, board type, occupancy, whether the price is net or carries the partner's margin, cancellation deadlines, minimum stay and any release dates for a room block. These are industry practices, not terms fixed by a regulation. One rate plan on the hotel side must correspond to exactly one rate plan on the partner side. A merged mapping is how the wrong price reaches a guest.
An allotment is a block of rooms the hotel releases to the partner. Free sale means the partner sells from the hotel's live availability. Both can run over the same connection, under different rules. Special offers such as early booking or long stay travel only if the partner's system has a field for the condition. If it does not, the offer stays manual, and someone has to remember that.
For dynamic rates the partner needs either a rule it can evaluate itself or a price the hotel sends. If the hotel sends prices, the frequency of the push becomes the accuracy of the price. Some things never travel: verbal promises, the phrase "we will always find a room", and any rate the hotel has not loaded.
How your prices sit against other channels is a commercial and legal question for your own adviser, not something the connection decides. For the practical steps of loading agency rates, see the contract loading checklist.
What has to be mapped and tested before go-live?
Every room type, rate plan, board type and cancellation policy the partner sells must be matched to its exact counterpart in the hotel's system, and then proven with test bookings in both directions.
Mapping is a list, not a feeling. Write it down room type by room type and rate plan by rate plan, and have both sides confirm the same document. Board types and occupancy rules need their own line: a room the partner sells as two adults plus a child must land as exactly that in the hotel's system. Currency and tax handling must be written down: which side converts, which side adds tax, and what the guest is quoted.
Test the ordinary and the awkward: a new booking, a modification, a cancellation, a stop sale, a sold-out date and a price change, each checked on both screens. The test is not finished when the booking appears on the hotel side. It is finished when the hotel's confirmation reaches the partner and the traveler. Agree who signs off and what evidence is kept, so that a later dispute has a starting point. More detail on this step is in channel manager mapping: room types, rate plans and testing.
ChecklistBefore go-live, confirm each item
- Room type mapping confirmed by both sides
- Rate plan mapping one to one
- Board and occupancy rules agreed
- Currency and tax handling written down
- One test booking completed, modified and cancelled
- A stop sale and a sold-out date tested
- Confirmation reaching the partner verified
- Named contacts and escalation route agreed
What happens when a booking fails or arrives twice?
Failures are ordinary: a message times out, a retry sends the same booking twice, or a room sells in the seconds between a search and a booking. What matters is who notices and who fixes it.
The common shapes are few. The partner confirms to the traveler but the hotel's system never receives the booking. The hotel receives the same booking twice after a retry. The hotel receives a booking for a rate plan it has already closed. A booking sent twice must land once. The partner's own booking reference is what lets the hotel's system recognise a repeat, which is why that field belongs in the mapping discussion.
The partner usually notices first, because the traveler holds a confirmation. The hotel often learns at the front desk, when the guest is standing there. The agreement should name a contact on each side, a response time, and a daily reconciliation of bookings between the two systems. Reconcile on a routine, not after a complaint: a short daily list of bookings received through the connection, matched against the hotel's own records, catches most gaps while they are still cheap.
Overbooking at the property is a service problem before it is a legal one. How a confirmed reservation must be honored is a question for your adviser, and no connection can settle it.
Watch outA booking that exists on one side only is not a technical detail
It becomes a guest at the front desk holding a confirmation the hotel cannot find, and the fix costs more than every test that was skipped.
What should a hotel ask before switching off manual loading?
Run the connection and the old manual process side by side until the connection has proved itself on the rate plans that matter, then switch off one rate plan at a time.
Parallel running means loading both ways for a defined period and comparing what arrived through each route, including the bookings that arrived only one way. Check coverage, not just the main rate plan: every rate plan the partner sells should be mapped and tested before any manual route is closed. Check closure behaviour: what happens to a stop sale, a sold-out date and a closed-to-arrival rule when they are sent over the connection.
Name who watches the connection at night and at weekends, and what that person does when a message fails. Agree the exit before you need it: how the connection is turned off, and how the hotel returns to manual loading without losing bookings already in flight. Keep a daily report of bookings received through the connection, matched against the hotel's own records. The report is the evidence that switching off was safe.
The decision rests on trust in the mapping and in the reconciliation habit. The format of the data is the least interesting part of it. If you are still choosing the system that will hold these connections, the questions in how to choose a channel manager come before any of this.
Key pointSwitch off manual loading one rate plan at a time
Do it after a parallel period in which both routes ran and were compared. A connection that has never been compared has never been tested.
What to do next
Before the next connection call, ask for two documents in writing: the mapping list and the daily reconciliation routine. Everything else in this article, what travels, who speaks first, how rates are carried, follows from those two, and they are what decide whether the connection removes work or creates a new kind of error.
On our own side, partners and AI assistants are meant to connect to AI Otel through a versioned, secured booking API and to receive signed booking events, each carrying proof of who sent it. It is built, with no partner connected yet; the design is described on the distribution page. If you want to discuss how your hotel's connections are set up today, request a briefing.
Frequently asked questions
Is XML still used, or has it been replaced by APIs?
XML is a way of labelling data, and an API is a way for two systems to ask each other for things, so the two words answer different questions. The label on a connection does not decide the outcome; the agreement on fields, timing and responsibility does.
Does an XML connection mean the hotel no longer loads rates by hand?
Only for the room types and rate plans that are mapped and covered by the agreement. Anything outside that list stays manual. Run a parallel period before closing any manual route, and switch off one rate plan at a time.
Who is responsible when a booking fails to reach the hotel?
It depends on the contract between the hotel and the partner, and on what each side was obliged to do. The traveler's confirmation and the hotel's acceptance are separate steps. Agree a named contact on each side, a response time and a daily reconciliation; how a confirmed reservation must be honored is a legal question for the hotel's adviser.
Can a bedbank resell my rooms to agencies I never contracted with?
That is exactly what the contract has to settle: whether onward resale is allowed, at which rate type, and whether the bedbank may pass the price on. Practice varies between partners. Read the clause before signing and confirm your own position with an adviser.