AI guest messaging for Smily, formerly BookingSync
Smily accounts cannot connect to TravelPal yet. TravelPal has not finished its own setup with Smily.
One Smily connection works in both directions. Each item is explained below.
What TravelPal reads from Smily
Smily is used by European vacation rental managers, many of them French speaking. Their bookings come mostly from Airbnb and Booking.com. Many still call the system BookingSync.
Rentals become properties
TravelPal reads your rentals, bookings, and clients. From each rental it takes the name, address, city, rental type, and photos. It takes how many it sleeps and the bedroom counts. It also takes your check-in hour, check-in cutoff, and check-out hour. Smily keeps a summary and a description for each language. TravelPal uses the English one where you have it, and the one you wrote where you do not. A rental described only in French can be answered without being rewritten.
Bookings, read by the status Smily gives them
Booked is a stay and is set up as a stay. Tentative is a hold and is treated as a hold. A booking marked Unavailable is a block your team put in the booking list. A season block is one example. It is never greeted and never gets a guest link. A booking that another application has Locked is left alone, and your team is told. Smily announces every booking when it is created, changed, or deleted. It does not promise those announcements arrive in order. So TravelPal reads the booking again, and does not trust the last announcement to be the current state.
The conversation, and which side each line came from
A Smily inbox conversation arrives with its earlier messages. Smily marks every person in it as Host or Client. So the concierge knows which lines were from your team and which were from the guest. It picks up a stay in the middle of a thread. It does not ask what your team already answered.
A Client is a person, not a booking row
Smily keeps travelers as Client records that last longer than one booking. A guest who stayed with you in May is known again in September, not met as a stranger. Their preferred locale comes 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. This is where hosts keep lockbox and keypad codes. It also has private notes and owner notes. A booking carries a door key code and payment links. None of this reaches the material the concierge answers from. So a code is never read out because someone typed it into a rental. See how we handle sensitive detail.
What TravelPal writes back to Smily
Every message goes out through Smily, never around it. So your Smily inbox shows exactly what each guest was told.
Replies travel on the conversation's own channel
Smily sends a message on to Airbnb, Booking.com, Vrbo, Expedia, or email on one condition. The message must carry that conversation's default channel. A message without it is accepted, given an id, and stored in Smily. But the guest never sees it. TravelPal reads the default channel from the conversation on every send. It refuses to post at all when 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 question TravelPal is holding for a person sits in the thread your team already reads. There is no second tool to check. A note for your team cannot reach the guest. An internal message may not carry a channel. The channel is the only way out to the platform.
Each sale is emailed to your team
On Smily, TravelPal sells the extras you price yourself, like a damage waiver or an extra clean. Each sale is emailed to your team, so nobody has to find it in Smily. Early check-in and late checkout are not sold on a booking that came from Smily. TravelPal changes no check-in or check-out time on a Smily booking.
Extra nights go to your team, not onto the booking
TravelPal moves no dates on a Smily booking. When a Smily guest asks for another night, your team gets the request and the dates. Your team makes the change in Smily. A guest who booked on Airbnb, Booking.com, Vrbo or Expedia is pointed to the channel's own change flow. TravelPal still sells your paid extras at your prices. See what gets sold.
Connected in four steps
Connecting Smily is work in progress. TravelPal's setup with Smily is not finished.
The application side is settled with Smily first
The credentials that let an application reach Smily accounts come from Smily's own partner panel. They belong to the application, not to you, and Smily counts every request against that application. We arrange this with Smily's partner team, and it is not finished yet. Until it is, Smily accounts cannot connect. There is no key for you to make.
Authorize from your own Smily account
Smily's authorization page is still on the bookingsync.com domain. You sign in there and approve the whole set on one screen. That is read on rentals, bookings, and clients, read and write on the inbox, and write on bookings. Approve all of them together. Smily will not add a missing one to an authorization it already issued. A partial approval means you sign in again.
Nothing to switch on inside your Smily settings
Booking and message announcements are registered once for the application, not account by account. After you authorize, updates reach TravelPal. You change nothing in your own Smily dashboard.
Rentals and bookings import in the background
Smily publishes a limit of 1,000 requests an hour for an application. Set each property's time zone while the import runs, because Smily does not publish one. Then every booking gets its own private guest link: how the whole thing runs.
TravelPal shows the connection at every step: connected, last update, and any error in plain words. To see the other setup steps, read what onboarding involves.
What the Smily connection will not do
Know the limits of Smily before you turn anything on. Every property management system has its own limits. TravelPal works inside them, not around them.
The channel opens the thread, and decides who may speak in it
Smily brings a conversation in from Airbnb and Booking.com. This usually happens within a few minutes of the booking. Smily's own documentation says it can take 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. Where the channel added none, TravelPal holds the thread for your team. It does not add one of your people as a speaker. A booking that never gets a channel thread is reached through its own guest link instead. This is most often a direct booking.
Smily publishes no time zone for a rental
A Smily rental has a city, a country, and coordinates, but no time zone of any kind. So quiet hours, scheduled messages, and cutoffs for paid extras need another time zone. They use the one set on the property in TravelPal. Set it during setup. Do it property by property if your portfolio spans countries. If you do not, 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. The same channel can be spelled three ways across three accounts. Where TravelPal cannot tell that a source is a direct booking, it refuses the date change. It will not rewrite a channel's booking behind its back.
No availability is read and no night is blocked
TravelPal does not quote availability from your Smily availability map. The only documented way to hold a night in Smily is to create a booking marked Unavailable. That booking would show in your own booking list, so TravelPal does not create one.
When TravelPal's AI is not sure, it stops and asks your team instead of guessing. This rule is the same on every system: see the safety guardrails.
Smily integration FAQ
Is Smily the same thing as BookingSync?
Yes. BookingSync was renamed Smily, and both names still appear, in the product and in older accounts. The authorization page is still on the bookingsync.com domain. The connection is built on Smily's own v3 API. It 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. We arrange that with Smily's partner team, and it is not finished yet. So Smily accounts cannot connect for now. Your part is one sign-in at Smily's authorization page. There you approve read access to rentals, bookings, and clients. You also approve read and write on the inbox, and write on bookings.
When does the first message reach a Smily guest?
No Smily guest gets a message today, because Smily accounts cannot connect yet. When they can, it comes after the booking channel has opened the thread. Smily brings a conversation in from Airbnb or Booking.com after the booking. This is usually within a few minutes and sometimes up to an hour. An application cannot start a thread that the platform would carry. TravelPal answers in that thread as soon as it exists. Guests whose booking never gets a thread are reached 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. TravelPal uses it for anything it is holding for a person to answer. An internal message may not carry a channel. The channel is the only way out to Airbnb or Booking.com. So the note stays on your side of the inbox. Everything the guest was told is in the same thread, in plain sight.
Not the system you use?
TravelPal connects to 33 property management systems. Below are the systems closest to Smily in how widely they are used.
Updated
Smily is a trademark of its owner. TravelPal is not affiliated with or endorsed by Smily.