AI guest messaging and upsells for iGMS
TravelPal connects to iGMS through the iGMS developer program, then answers your guests in the channel thread they already wrote in: Airbnb, Booking.com, VRBO, and email for a booking taken inside iGMS itself. It reads the property rather than the channel listing, so an apartment on three marketplaces carries one set of house facts, and it counts a night free only when every listing under that unit agrees. What a guest buys is priced, sold, and handed to your team with the time on it, because iGMS keeps booking edits to bookings made inside iGMS.
One connection, running both ways. Every item on it is detailed below.
What TravelPal reads from iGMS
iGMS is run by hosts and property management companies whose stays arrive from Airbnb, Booking.com, and VRBO, with direct bookings taken inside iGMS rather than on a site of their own.
One property per unit, not one per channel
iGMS keeps two levels: a property, which is the apartment, and its listings, one for each marketplace that apartment is published to. TravelPal reads the property, so a unit on Airbnb, Booking.com, and VRBO carries one set of house facts, one check-in and check-out time, and one guest link behind all three rather than three that drift apart. Address, bedrooms, beds, and bathrooms arrive with it.
Bookings announce themselves, and a sweep catches the rest
iGMS announces a booking when it is created or changed, and each announcement carries its own id, so the same change is never acted on twice. TravelPal also re-reads every booking iGMS has updated since a given day, which is the finest window iGMS offers and is how anything an announcement missed still lands. A booking becomes a stay once iGMS marks it accepted, and a canceled, declined, or expired one closes it out. iGMS lists its other booking statuses without defining them, so where a word could mean a confirmed booking or an inquiry that never became one, TravelPal raises the stay with your team rather than greeting somebody who has not booked.
Every booking names the platform it came from
iGMS records the platform on the booking itself: Airbnb, Booking.com, VRBO under either VRBO or its older HomeAway name, or a booking taken inside iGMS. That decides which rail the guest is answered on and what TravelPal is allowed to offer them, and it is why a channel guest is never contacted around the channel. The reservation code read back to a guest is the one iGMS shows them, never the internal key iGMS files the booking under.
Guests are records, and threads arrive whole
iGMS stores a guest as a record of their own rather than as contact details copied onto each booking, so a repeat booker arrives with their history attached instead of as a new name. A thread comes back with its messages already inside it, in a single read, so TravelPal has the whole conversation before it says anything. iGMS never states the order those messages arrive in, and its own examples run newest first, so TravelPal puts the conversation back in time order before reading it.
Availability read across every channel listing
iGMS answers the calendar with one row per channel listing per date, and two rows for the same night can disagree. TravelPal counts a night free only when every row for it agrees, so a night another marketplace has already sold is never offered again. The nightly rate iGMS returns is what you take before channel markups, which is the right floor to price an upsell against and not what a guest sees on a marketplace, and the minimum stay comes with it.
What TravelPal writes back
Every message goes out through iGMS, never around it, so your own inbox shows exactly what each guest was told.
Replies in the platform thread
iGMS sends on two channels and calls them platform and email. A channel guest is answered inside the thread they already see, in Airbnb, in Booking.com, in VRBO, and TravelPal names the channel on every send rather than letting iGMS fall back to its default. iGMS carries no guest language on any record, so the first reply goes out in your default language and the guest can switch to their own on their stay page.
Email for bookings taken inside iGMS
A booking made inside iGMS rather than on a marketplace has no platform thread, so that guest is answered by email, and only where iGMS holds an address for them. The send carries no address of its own, so where iGMS holds none the stay is raised with your team instead of a message being accepted and delivered nowhere.
A send is checked, not assumed
iGMS accepts a message first and delivers it afterward, and it keeps the outcome on a separate record whose published values include paused and disabled alongside completed. TravelPal reads that outcome, so a message your account was never going to deliver reaches your team as something to fix rather than sitting in our records as a reply the guest read.
Connected in four steps
iGMS switches API access on for your account, and TravelPal does the rest itself.
Open Developer Program inside iGMS
It is in the iGMS app, under Developer Program, and the client ID for the connection is on that page. You submit a short description of what the connection will do with your account, and iGMS publishes a review time of two to three business days.
Ask iGMS support for the access
The messaging and calendar access is granted by iGMS against that client ID, by email, rather than from a settings screen, and the booking announcements are switched on the same way. One message covers both. We send you the exact wording and the address the announcements should be sent to, and you can ask us to be on the email.
Authorize TravelPal, then paste the client ID and token
You approve the access from your own iGMS account, and iGMS issues one access token with no published expiry and nothing to refresh it with, so it is pasted once. TravelPal checks it on the spot against both your properties and your channel listings, so a permission that did not come through is a refusal you see on the connect screen rather than a connection that succeeds and imports nothing.
Properties import, and you set the time zone once
Your properties become units with their check-in and check-out times, and every booking after that, on any platform iGMS carries, gets its own private guest link. iGMS records a unit's offset from UTC rather than a named time zone, and an offset does not carry daylight saving, so the zone is set once in TravelPal and quiet hours hold through the year.
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 iGMS connection will not do
Every property management system draws its own lines, and the ones iGMS draws are worth knowing before you switch anything on. TravelPal works inside them rather than around them.
The only note field in iGMS is on the calendar
Both of the channels iGMS sends on, the platform thread and email, are seen by the guest. The one place iGMS takes a note is against a range of calendar dates, which no conversation ever reaches. So there is nowhere inside iGMS to put a line meant for your side, and TravelPal does not invent one: sale notes and anything held for a person reach you in your own channel and by email.
What a guest buys reaches your team, not the booking
Every booking edit iGMS publishes is marked for bookings made inside iGMS, and the one that could move a date asks for the whole booking to be restated, its price included. TravelPal will not restate a price it was not asked to touch, and it holds no nights on your iGMS calendar either, because nothing in iGMS records who created a block and releasing one we did not make would put your own maintenance dates back on the market. A sold late checkout is priced, taken, recorded on the stay, and handed to your team with the time on it. See how upsells are sold.
A returning guest is recognized per platform
iGMS gives each guest a record of their own, which is why a repeat booking arrives with its history. That record is scoped to the platform the guest booked on, so one person who stays once through Airbnb and once on a booking taken inside iGMS is two guests here, and iGMS offers no way to join their two stays.
Booking changes are announced, guest messages are read
iGMS switches on announcements for four kinds of record: bookings, calendars, properties, and guests. A guest message is not one of them, so a new message is picked up when TravelPal reads the threads rather than the instant it lands. iGMS also marks each message with a sender id and no sender role, so a line typed by one of your people, one sent by an iGMS automation, and one sent by TravelPal are a single undivided side of the conversation. A thread therefore reaches a person on your rules and your quiet hours, never on TravelPal having spotted a colleague typing.
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.
iGMS integration FAQ
Does iGMS have to switch anything on before TravelPal can connect?
Yes, and it is a short exchange with iGMS rather than a form you fill in alone. Access to the messaging and calendar parts of iGMS is granted by iGMS support, not toggled from a settings screen. Your client ID sits on the Developer Program page inside the iGMS app, you submit a short description of what the connection will do, iGMS publishes a review time of two to three business days, and support then grants the access and switches on the booking announcements against that client ID. You authorize TravelPal from your own account and paste the client ID and access token in.
Which channels does the iGMS connection cover?
The platforms iGMS itself carries: Airbnb, Booking.com, VRBO under either VRBO or its older HomeAway name, and bookings taken inside iGMS. A guest who booked on a marketplace is answered inside that marketplace's thread. A guest whose booking was taken inside iGMS is answered by email, where iGMS holds an address for them.
Will my team still see what guests were told?
Yes. Every reply is posted through iGMS, so your own iGMS inbox holds the same conversation the guest holds. What will not be in that thread is anything meant only for your side: iGMS sends on the platform thread and on email, a guest sees both, and its one note field belongs to a range of calendar dates rather than to a conversation. So sale notes and anything held for a person reach your team in your own channel and by email.
Can TravelPal change an iGMS booking?
No. Every booking edit iGMS publishes is marked for bookings made inside iGMS, and the one that could move a date requires the whole booking to be restated, price included, so TravelPal does not touch it. A late checkout a guest buys is sold at your price, recorded on the stay, and handed to your team with the time on it. On systems that open booking edits to us, TravelPal writes the change itself.
Updated