AI guest messaging for Smily, formerly BookingSync
TravelPal answers your Smily guests in the conversation the booking channel opened, whether that thread came from Airbnb, Booking.com, Vrbo, or Expedia. It reads your rentals, bookings, clients, and availability map, sells upgrades at your prices, and moves the expected check-in or check-out time on the booking itself. Anything meant for your team goes into the same Smily conversation at internal visibility, which cannot carry a channel and so never leaves your side of the inbox.
One connection, running both ways. Every item on it is detailed below.
What TravelPal reads from Smily
Smily is run by European vacation rental managers, many of them French speaking, whose bookings arrive mostly from Airbnb and Booking.com and who still call the system BookingSync.
Rentals become properties
Name, address, city, rental type, sleeps and bedroom counts, photos, and your check-in hour, check-in cutoff, and check-out hour arrive from Smily. Smily holds a summary and a description per language, so TravelPal takes the English one where you have it and the one you actually wrote where you do not: a rental described only in French is answerable without being rewritten.
Bookings, read by the status Smily gives them
Booked is a stay and is provisioned. Tentative is a hold and is treated as one. A booking marked Unavailable is calendar furniture, the season block your team put in the booking list, so it is never greeted and never gets a guest link, and one that another application has Locked is left alone and raised with your team instead. Smily announces every booking as it is created, changed, or deleted, and does not promise those announcements arrive in order, so TravelPal re-reads the booking rather than trusting the last one to be the current state.
The conversation, and which side each line came from
A Smily inbox conversation arrives with its earlier messages, and Smily marks every participant in it Host or Client. So the concierge knows which lines were your team's and which were the guest's, and picks up a stay mid-thread instead of asking what your team already answered.
A Client is a person, not a booking row
Smily keeps travelers as Client records that outlive a single booking, so a guest who stayed with you in May is recognized in September rather than met as a stranger. Their preferred locale rides along, so the first reply is already in their language.
The fields TravelPal deliberately leaves behind
Smily's rental record has a check-in details field, which is exactly where hosts keep lockbox and keypad codes, plus private notes and owner notes, and a booking carries a door key code and payment links. None of it reaches the material the concierge answers from, so a code is never read out because somebody typed it into a rental. See how we handle sensitive detail.
What TravelPal writes back
Every message goes out through Smily, never around it, so your own inbox shows exactly what each guest was told.
Replies travel on the conversation's own channel
Smily relays a message to Airbnb, Booking.com, Vrbo, Expedia, or email only when it is stamped with that conversation's default channel. A message without it is accepted, given an id, stored in Smily, and never shown to the guest. TravelPal reads the default channel off the conversation on every single send, and refuses to post at all where a conversation has none, so nothing is ever recorded as delivered when the guest could not have seen it.
Team-only notes in the guest's own thread
Smily's inbox has an internal visibility, so a sale note, or a question TravelPal is holding for a person, sits in the same thread your team is already reading. There is no second tool to check, and no risk of a handover note reaching the guest: an internal message may not carry a channel, and the channel is the only route out to the platform.
Sold time changes on the booking
A paid late checkout or early check-in moves what Smily calls the expected check-out or check-in time on the booking, so your cleaners read the real hour. Smily requires the stay's dates on every booking write, so TravelPal re-reads the booking and resends them exactly as they stand, changing only the hour the guest bought.
Extra nights on direct bookings
An added night is checked against Smily's availability map before it is offered, then written as a real date change that keeps the check-in and check-out hours the booking already has. Date changes on an Airbnb, Booking.com, Vrbo, or Expedia booking are refused, and the guest is pointed at the channel's own change flow. See what gets sold.
Connected in four steps
Smily switches API access on for your account, and TravelPal does the rest itself.
The application side is settled with Smily first
The credentials that let an application reach Smily accounts come from Smily's own partner panel and belong to the application rather than to you, and Smily counts every request against that application. That side is arranged between us and Smily's partner team, and there is no key for you to generate.
Authorize from your own Smily account
Smily's authorization page still sits on the bookingsync.com domain. You sign in there and approve the whole set in one screen: read on rentals, bookings, and clients, read and write on the inbox, and write on bookings. Approve all of them together, because Smily will not add a missing one to an authorization it has already issued, and a partial approval means signing in again.
Nothing to switch on inside your Smily settings
Booking and message announcements are registered once for the application rather than account by account. Once you have authorized, updates start reaching TravelPal with no configuration anywhere in your own Smily dashboard.
Rentals and bookings import in the background
The import is paced against the 1,000 requests an hour Smily publishes for an application, so a large portfolio fills in over the first hours rather than all at once. Set each property's time zone while it runs, because Smily does not publish one. Then every booking gets its own private guest link: how the whole thing runs.
The dashboard shows the connection the whole way: connected, last sync, and any error in plain words. The rest of going live is covered in what onboarding involves.
What the Smily connection will not do
Every property management system draws its own lines, and the ones Smily draws are worth knowing before you switch anything on. TravelPal works inside them rather than around them.
The channel opens the thread, and decides who may speak in it
Smily syncs a conversation in from Airbnb and Booking.com, usually within a few minutes of the booking and, by Smily's own documentation, sometimes up to an hour. A thread started from outside is not connected to the platform and its messages reach nobody, so TravelPal waits for the real one. Only a Host participant may send in a Smily conversation, and where the channel added none, TravelPal holds the thread for your team rather than signing one of your people up to speak. A booking that never gets a channel thread, a direct booking most often, is reached through its own guest link instead.
Smily publishes no time zone for a rental
A Smily rental carries a city, a country, and coordinates, and no time zone of any kind. Quiet hours, scheduled messages, and upsell cutoffs therefore run on the time zone set on the property in TravelPal. Set it during onboarding, property by property for a portfolio spread across countries, or an evening message goes out in the morning.
The booking channel is a name your team types
Smily sources are free text with no fixed list, so the same channel can be spelled three ways across three accounts. Where TravelPal cannot recognize a source as a direct booking, it refuses the date change rather than rewriting a channel's reservation behind its back. Spell your direct sources plainly, website or direct or phone, and extra nights work on them.
The calendar is read, never written
Smily's availability map says a day is free or taken, counts a tentative hold as taken, and carries no nightly price, so extra nights are quoted from the rates you set in TravelPal. The only documented way to hold a night in Smily is to create a booking marked Unavailable, which would show up in your own booking list, so TravelPal does not create one.
Where the AI is not sure, it stops and asks your team rather than guessing. That is the same on every system: see the guardrails.
Smily integration FAQ
Is Smily the same thing as BookingSync?
Yes. BookingSync was renamed Smily, and both names still turn up, in the product and in older accounts, and the authorization page still sits on the bookingsync.com domain. The connection is built against Smily's own v3 API and works the same whichever name your login shows.
Do I need Smily's involvement to connect TravelPal?
Yes, on the application side. The credentials that let an application reach Smily accounts come from Smily's partner panel, and that is arranged between us and Smily's partner team before your account is touched. Your part is one sign-in at Smily's authorization page, where you approve read access to rentals, bookings, and clients, read and write on the inbox, and write on bookings.
When does the first message reach a Smily guest?
Once the booking channel has opened the thread. Smily syncs a conversation in from Airbnb or Booking.com after the booking, usually within a few minutes and sometimes up to an hour, and an application cannot start one that the platform would carry. TravelPal answers in that thread as soon as it exists, and reaches guests whose booking never gets one through their private guest link.
Can my team keep a note in the thread without the guest seeing it?
Yes. Smily's inbox has an internal visibility, and TravelPal uses it for sale notes and for anything it is holding for a person to answer. An internal message may not carry a channel, and the channel is the only route out to Airbnb or Booking.com, so it stays on your side of the inbox. Everything the guest was told sits in the same thread, in plain sight.
Not the system you run?
TravelPal connects to 33 property management systems. These are the ones nearest Smily in how widely they are used.
Updated