Webhooks and polling: how hotel systems learn that something changed
Webhooks push changes instantly but can fail silently, while polling pulls updates on a schedule. This guide explains the trade-offs, security needs, and vendor questions for reliable hotel integrations.
Contents
Key takeaways
- A webhook is a push: the sending system tells the receiving system that something changed, without being asked.
- Polling is a pull: the receiving system asks on a schedule, so the worst case is a delay of one interval, not a lost message.
- The dangerous failure is not a late message but a message that never arrives, which is why every webhook setup needs a periodic cross-check between the two systems.
- A receiving address that anyone can call is a door into the hotel's data: it must be unguessable and must check who is calling.
- Ask the vendor three things before signing: how long a retry lasts, how a missed event can be re-sent, and how the two systems are compared each day.
A webhook is a message one system pushes to another the moment something changes, such as a new booking. Polling is the opposite: one system asks the other every few minutes whether anything changed. Webhooks are faster but can be missed silently; polling is slower but leaves a trail you can check. This is the core of the webhook vs polling hotel integration decision.
For example, a guest upgrades to a sea-view room at 21:40 and the front desk sees it at 21:52. In those twelve minutes the old room was still on sale on three channels. Nothing was broken; the two systems simply learn about change in different ways. After reading this you will be able to name those two ways, judge what a few minutes of delay costs your hotel, and put specific questions about failure behaviour to any integration vendor.
What is the difference between a webhook and polling?
A webhook is a push and polling is a pull. With a webhook the sending system delivers a short message the moment a change happens; with polling the receiving system asks a question on a timer and gets an answer, changed or not.
The mail analogy, briefly
A webhook is a courier knocking on your door when a letter arrives. Polling is you walking to the post office every ten minutes to ask whether anything came for you. In both models the two systems stay separate and only small messages cross between them. Neither model means the hotel's data lives in the partner's system.
Polling has a fixed interval, for example every five minutes. The average delay is about half the interval and the worst case is the full interval, every time, predictably. A webhook normally arrives in under a second when everything works; the word to watch is "normally", because the delay is short on average but has no ceiling when something breaks. For a plain-language grounding in how systems talk at all, see hotel PMS integrations explained: APIs in plain words.
The same events underneath
Underneath, both models need the same thing: a defined list of events, such as booking created, booking modified, booking cancelled and room moved, and an agreed meaning for each one. Neither model is the modern one. The two solve different problems, so a mature setup often uses both on the same connection.
| Question | Webhook (push) | Polling (pull) |
|---|---|---|
| Who starts the conversation | Sender, the moment something changes | Receiver, on a timer |
| Typical delay | Near instant when working, no ceiling when not | Half the interval on average, one interval at worst |
| If the receiver is offline | The message must be retried or it is lost | Nothing is lost; the next question asks again |
| Where the load sits | Spread across events | A fixed load even when nothing changed |
| What the hotel must build | A reachable, protected address and a duplicate check | A schedule, a stored last answer and a comparison |
| How a gap is detected | Only by comparing the two systems | By the next successful answer |
The question to ask is not which is better but which failure you can live with: a delay you can measure, or a loss you cannot see.
What does a few minutes of delay mean for a booking?
It means a room can be sold twice, or a guest quoted the wrong price, in the gap between the change and the message. The size of that gap is a business decision, not only a technical one.
A new booking from a travel agency arrives. Until the hotel's system knows, the same room stays on sale on the hotel's own website and on every other channel. A cancellation is the mirror image: the room stays blocked and unsold until the message lands, which in high season is money lost quietly. A rate change is a quoting problem: for the length of the delay, a guest or an agency is offered yesterday's price, and honouring it is the hotel's choice. A room move is an operations problem: housekeeping is sent to the wrong room and the guest waits in the lobby.
Polling bounds the delay: one interval, known in advance. Webhooks make it usually tiny and occasionally unbounded, which is why the unbounded case needs a backstop. Set the mechanism per event type. A cancellation that frees a room in August deserves the fastest path available; a weekly rate plan does not.
For example, a 200-room hotel polling every five minutes in high season can hold a cancelled room for sale for up to five minutes after it was released. That is a choice, and it should be a written one. For how these delays behave inside a channel manager link, see how a channel manager connection works: messages, delays and errors.
What happens when a message is missed?
Nothing visible happens. The sending system believes it delivered, the receiving system never saw it, and the two systems now disagree until a person compares them.
Common causes are ordinary: the receiving system was restarting, the address changed, a network rule blocked the call, or the message was accepted and then failed while being processed. The dangerous part is the silence. No error appears on either screen, and the front desk usually learns about it from the guest at the door.
A message that arrives and then fails to process is worse than one that never arrives, because the sender may mark the job done and stop trying. Polling fails differently and more kindly: a missed poll is only a late poll, because the next question asks again and gets the current state.
Detection needs two things: a heartbeat, a small regular signal that proves the channel is alive, and a periodic full comparison of the two booking lists. Write down who reads the differences and how often. A comparison nobody opens is decoration.
Watch outSilence is not evidence
A missing message has no error message. If the only evidence that an integration works is that nobody has complained yet, you do not have evidence. Ask for the comparison report by name and see it once before you sign.
How do retries and a cross-check catch missed events?
Retries give a failed delivery more chances on a widening schedule; a cross-check compares the two systems on a fixed rhythm and repairs whatever the retries lost. One without the other is half a safety net.
The retry pattern is simple: try again after a short wait, then after longer waits, then stop after a set period. Ask what that period is, because after it the message is gone. Retries create duplicates: the same booking message can arrive twice, so the receiving system must recognise a repeat and not create a second reservation. Engineers call this property idempotency: the same message applied twice has the same effect as once.
Order is not guaranteed either. A "booking modified" message can arrive before "booking created", so the receiver needs a rule: if an update arrives for a booking it does not have, it asks for the original rather than guessing. Replay is the human override: a way to re-send one specific past event on demand, keeping its original time stamp so the record stays truthful.
The cross-check, sometimes called reconciliation, compares totals and individual bookings between the two systems, daily or hourly, and produces a list of differences a person can act on. A parking list for failures matters too: messages that failed repeatedly should be held for a person, not dropped silently after the last attempt.
Key pointFour safety nets, in order
Retry: more attempts on a widening schedule. Duplicate check: a repeat must not create a second booking. Replay: re-send one past event on demand. Cross-check: compare the two systems on a rhythm and repair the differences.
Why must a receiving address be protected?
Because a webhook address is a door. Anyone who learns it can send a message that looks exactly like a booking, and the hotel's system will act on it.
The address should be long, random and unguessable, and treated like a password: not pasted into shared documents, screenshots or support tickets. The receiver must check who is calling, which means a shared secret carried in the message, or a signature computed over the message content that only the two sides can produce. The message should travel over an encrypted connection, so the content cannot be read or altered in between.
Old messages must not be accepted twice. A correctly signed message from last week is still an attack if it is replayed, so the receiver checks the time stamp and accepts only a short window. Keep the message small: a booking reference and the change, not the guest's full personal data. Every copy of a message is another place personal data lives, and personal data carries duties under KVKK, the personal data protection law. Log every received message with its time and its result; when a partner says they sent something, the log settles the argument.
NoteRotate the address like a password
Treat the receiving address as a password with a rotation date. If a staff member who knew it leaves, or if it appears in a screenshot, change it and tell the partner the new one.
Which jobs suit webhooks and which suit polling?
Use webhooks for events that must be known quickly, polling for anything that must not be lost, and both for the small set of events where a mistake costs a room.
| Job | Mechanism | Reason |
|---|---|---|
| New booking | Webhook, with polling as backstop | The room must leave sale immediately |
| Cancellation or modification | Both | Frees or changes inventory, so delay and loss both cost |
| Rate and availability sync | Polling | A fixed rhythm is acceptable; the full picture matters |
| Group block release | Both | Large inventory moves at once |
| Daily comparison | Neither; it is the backstop | Catches what both models missed |
Webhook first: new booking, cancellation, modification, payment status, and room status changes during a stay. Polling first: rate and availability sync to channels, where a fixed rhythm is acceptable and the complete picture matters more than the instant. Both together: cancellations in high season, group block releases and anything that frees inventory, because these are the events where a loss is expensive and a delay is also expensive. Neither replaces the daily cross-check, which is the backstop under both models.
Cost is real. Polling asks even when nothing changed, so a short interval across a large inventory loads both sides, and providers cap how often you may ask. Ask whether the mechanism is documented and testable before signing. An integration you cannot test in a quiet week is an integration you will test in August. For the older, contract-heavy side of this world, see XML connections with tour operators and bedbanks: what a hotel agrees to, and for the security words vendors use, a versioned, OAuth-secured booking API: what each word means for a hotel.
What should a hotel ask an integration vendor?
Ask about failure behaviour, not the feature list: what happens when a message is late, lost, duplicated or refused. A vendor who can answer these questions has thought about the front desk.
The answers should be specific and written, not reassuring. "It always works" is not an answer to any question below. Ask for the comparison report once during the trial, and read it with your front office manager. Ask who is called at 02:00 and what response time is agreed, and put that in the contract rather than the sales deck.
ChecklistAsk the vendor, and keep the answers in the file
- Which events do you send, and which do you only answer on request?
- If our system is down for an hour, what happens to the messages from that hour?
- How long do you keep retrying, and where can we see what failed?
- Can you re-send one specific past event, and does it keep its original time?
- How do you stop the same booking being created twice?
- How do we compare our two systems, how often, and who reads the differences?
- How is the receiving address protected, and how do we change the secret?
- What is the polling interval, and what is the cap on how often we may ask?
- Who do we call at 02:00, and what response time is agreed?
What to do next
Before you sign an integration, ask the vendor to walk you through one lost message from end to end: how it is noticed, how it is re-sent, and who compares the two systems at the end of the day. Push and pull are only the transport; the difference between a calm front desk and a double booking sits in the retries, the duplicate check and the daily comparison behind them.
Frequently asked questions
Is a webhook the same thing as an API?
No. An API is the general way two systems are allowed to talk to each other; a webhook is one direction of that conversation, where the sending system calls the receiving system without being asked. Polling also uses the API, in the other direction: the receiver calls the sender and asks a question.
How often should a hotel poll?
Match the interval to how long a stale answer can stay on sale. A cancellation that frees a room in high season justifies a short interval; a weekly rate plan does not. Shorter intervals cost load on both sides and run into the provider's cap on how often you may ask, so the interval is a written trade-off, not a default.
Can a webhook message be lost for good?
Yes. If the receiving system stays unreachable past the end of the retry period, the message is gone unless it can be replayed or the two systems are compared. That is why a webhook setup without a periodic cross-check is incomplete.
Do we need both webhooks and polling?
For booking-critical events, usually yes. The webhook gives speed, polling gives a floor under the delay, and the daily comparison catches what both missed. For low-value, high-volume sync such as rates, polling alone is often enough.
Does the receiving system need to be reachable from the internet?
Yes, for a webhook: the sender has to be able to call it. A system kept behind a closed network cannot receive one directly and either needs a relay in between or must poll instead. This is one practical reason some hotels' on-premise systems still poll.
