One calendar for Airbnb and Booking.com, joined up with iCal

How StaySuite reads your Airbnb, Booking.com and Vrbo calendars every twenty minutes and publishes yours back, and why it is not a real-time channel manager.

Portada: One calendar for Airbnb and Booking.com, joined up with iCal

Picture a stone farmhouse in the hills above Cómpeta that is listed on Airbnb, on Booking.com and, since last summer, on a Spanish rural-tourism site your cleaner told you about. Three calendars, three logins, three sets of rules. In July a family books the second week on Booking.com on a Tuesday evening. On Wednesday morning a couple from Dublin asks for those same nights on Airbnb. Nobody has done anything wrong, and somebody is about to be told the house is not available after all. This is the situation the article on the guest who writes to three places at once describes, and the calendar is where it begins.

StaySuite's answer is deliberately modest. It uses iCal, the plain calendar format that every portal already offers, to make your portals agree with one another through a single calendar that sits in the middle. It works well for a house or a handful of houses. It is not magic, and the limits are in a section further down, because you should know them before you rely on it.

What happens when you connect a calendar

In the Calendars tab of your panel, you pick the property and paste the iCal address (a link ending in .ics) that the portal gives you in the calendar settings of your listing. StaySuite works out which portal it is from the web address: Airbnb, Booking.com and Vrbo (including its sister sites such as HomeAway, Abritel and FeWo-direkt) are recognised, and anything else, a rural-tourism site or Google Calendar for example, is filed under Other. You can correct the choice if it guesses wrong.

The moment you connect, StaySuite reads the calendar once and blocks those nights in your own calendar. From then on it reads it again roughly every twenty minutes. There is a Read now button if you have just taken a booking and want it reflected immediately; press it twice in a minute and it asks you to wait. Each rental can have up to ten calendars connected, which covers the usual mix of portals with room to spare.

A word on the address you paste. The iCal link from Airbnb and Booking.com contains a secret token that gives read access to your calendar, so it is a credential and not just a link. StaySuite stores it encrypted and shows only the host name in the panel, never the full address.

20 minhow often StaySuite re-reads each connected portal calendar when everything is working

Publishing yours back, one address per portal

Reading is only half the job. For Airbnb to know that Booking.com has taken your nights, it needs to read a calendar that includes them. So StaySuite also gives you an address to paste into each portal as an imported calendar. There is one address per portal, and that is on purpose: the calendar you give Airbnb contains your own bookings, your manual blocks and whatever came from the other portals, but never what came from Airbnb itself. Sending a portal its own bookings back creates an echo, where a cancellation on the portal would leave a ghost block here until the next round trip.

Two further details are worth knowing. The published calendar looks eighteen months ahead, and cancelled or no-show bookings are left out so that a night you have freed up is not still shown as taken. And the address can be regenerated at any time: the old one stops working immediately and you paste the new one into the portal.

Privacy: what the other portals see

Anyone who has the link can read the calendar, because iCal has no log-in. That is a property of the format, not of StaySuite. So the export is built so that it cannot carry personal data even by mistake: each entry is a start date, an end date and one of two generic labels, Reserved or Not available. The guest's name, phone number and email address have nowhere to go. If the link is ever forwarded by email, what a stranger would learn is which nights are taken, which they could also see on the portal's public page anyway.

When a portal misbehaves

Portals are not always reliable, and the design assumes that. If a read fails, because the portal returned an error, took too long, or sent back something that is not a calendar, StaySuite keeps the last good state and records why. It will not unblock your August because Booking.com had a bad afternoon. The retries back off from twenty minutes to forty, eighty and so on, up to six hours, so a portal that is down is not hammered, and the first successful read after it recovers brings everything straight again. The panel shows when each calendar was last read, when it last succeeded and when the next read is due, and it tells you in plain words if reads have been failing.

One rule runs the other way. A calendar that arrives intact but empty is believed. If you cancel every booking on a portal, those nights are freed here on the next read. A valid answer from the portal is a statement of fact; only an error is treated as no information.

Where it helps in practice

The calendar is not just a diary. When a booking request arrives in your panel, taken by the assistant, StaySuite checks it against the calendar and flags it if those nights are already occupied by another booking, a manual block or a reservation that came in from Airbnb or Booking.com. You will not accept a request on top of a portal booking without being told. If you try to accept one that clashes, the panel stops you and says why. The same calendar answers the guest. When someone asks the assistant, or the "Check dates" form on your property page, whether dates are free, the answer comes from this single calendar: your bookings, your blocks and the imported nights. If any imported calendar has gone more than three hours without being read properly, neither of them says the dates are free: they say they cannot check right now and pass the request on. The assistant never confirms a booking either way.

What it does not do

  • It is not a real-time channel manager. There is a delay of up to about twenty minutes in one direction, and each portal re-reads your published calendar at its own pace, which can be several hours. A booking that lands in that gap can still be double sold. If your house is booked solid every summer weekend, that gap matters, so use the portals' own instant-booking settings with care.
  • It does not synchronise prices, descriptions, photos or availability rules. It moves occupied nights, nothing else.
  • It does not copy the guest's name or message from a portal. What it imports is the fact that the nights are taken and which portal took them, not the contents of the booking.
  • It does not read portal inboxes. Messages still arrive where the portal sends them.
  • A request you accept in the panel changes the status of that request. It does not by itself write a booking into the calendar, so block the nights yourself so that the other portals close them too.

Who it suits, and which plan

If you run one house, or a few in the same area, and you already live with two or three portals, this removes the most tiresome part of it: the daily comparison of calendars. If you manage dozens of properties with high turnover, you probably need a true channel manager and should say so to yourself now rather than in August. The calendar connection is part of every StaySuite plan. The one-property plan is €29 a month on the annual rate (pioneer price, excluding VAT, with the normal rate at €59), the plan for up to three properties is €49, and the manager plan for up to ten is €99. The three-property plan adds a single calendar across all of them.

The easiest way to judge it is to try it. Open the demo, connect a calendar from one of your own listings, and watch the nights appear in your panel. You will see quickly whether it fits the way you work.

Ver todos los artículos