Live Connections

• Viator – every 12 to 24 hours
• GetYourGuide – every 8 days – fetch next 365 days, every 4 days – next 90 days, every 24h – next 30 days, every 6h – next 7 days
• Google – every 24 hours
• Expedia – every 24 hours

Best Practice: It’s best to not give clients exact timelines in case the call takes longer than expected.

Affiliate blocks do not limit API partners capacity to book. Affiliate blocks reserve spots just for the partner, but once those are filled, they will be able to book into the remaining spots as well. Affiliate blocks only prevent direct and online bookings in those spots. We do not limit capacity for affiliates.

Customers booking through an OTA will pay the price listed in the OTA. GYG is the only Channel API that can pull pricing from FareHarbor (when enabled at the product level). However, it’s a good idea for pricing in FareHarbor to match so clients can accurately report on affiliate bookings in FareHarbor.

All API bookings require payment to be collected in full by the OTA. This means that refunds must also be handled by the OTA. Cancelling and/or refunding a booking in FareHarbor does not cancel/refund the booking for the customer. Customers must contact the OTA they booked through to make changes to bookings or to receive refunds for cancelled bookings.

FareHarbor confirmation emails must be manually sent to confirmed API bookings using the email/text feature on the booking overview.

Exception: Google automatically sends FareHarbor’s confirmation email.

Since Smartwaiver is a custom field, the client can enable “SmartWaiver” as a whole-booking custom-field on the booking overview. Here’s a helpful how-to on adding custom-field information to an existing booking.

From there, clients can manually send their booking confirmation email so that customers can access the Smartwaiver ahead of time.

Custom fields set up in FareHarbor are not populated by API bookings. Any information gathered by an OTA at the time of booking will be sent as a booking comment at the bottom of the FareHarbor booking, as shown below. If clients need to collect pickup information from customers and their product is set up to collect that information in the OTA, that info will be sent through in the booking comments.

If clients need information to populate their custom fields so that it’s visible on the manifest, they can add custom-field information to an existing booking (without having to rebook), steps on that here.

QR codes are now supported for API bookings from Viator, GYG, and Expedia which means that the FH QR code will be passed through to Viator/GYG/Expedia and show on the customer’s voucher. Clients who have ticket scanning enabled in FH and Viator/GYG/Expedia will now be able to scan the FH QR code on a customer’s Viator/GYG/Expedia voucher to check them in. Note: we send QR codes at the TourBarcode level, meaning that one QR code is provided per booking, rather than per traveler.

Client Facing Help Page

Viator generates a temporary, traveler-protected email for each customer randomly at the time of booking. Clients can use this to follow up directly with their Viator customers. The traveler-protected email forwards communication to the customer’s personal email. The temporary email is valid for 30 days post date of travel.

Viator sends their own confirmation email and cancellation email if the booking is cancelled through their platform.

All Viator timestamps are written as hh:mm:ss with UTC, Coordinated Universal Time, when the booking took place. UTC is 7 hours ahead of Mountain Time all year round.

Google is a great tool to search and convert a time provided in UTC to your local time zone.

• Shared Capacity. The availability capacity reflects a combined capacity of two different shared resources which is generally incompatible with the API connection.. For example, an availability that has a capacity of 2 ATVs and 5 UTVs, the collective capacity reads 5. An additional example, could be combined public and private booking on a single availability.
• Do Not Allow Split Parties. The availability reads a remaining capacity of 2, but with do not allow split parties enabled, you can only book 1 person on Vehicle 1, and one person on Vehicle 2. This is generally incompatible with the API connection.
• Openers. The API integration can’t prevent a booking that does not qualify the correct opener ratios set within FareHarbor’s resource settings. For example, the end-customer must select at least 2 Adults for every 1 Child, but the OTA customer checks out as 1 Adult and 2 Children. The booking is ultimately allowed and results in an invalid availability error.
• Mapping Issue. Always check to see if all ticket type mapped are pulling the same # of future availability, if not, this typically indicates that a ticket type has been removed from future availability (for example, the client may have removed an age group, Infants, from being eligible to book a tour). This can be fixed by either adding the missing FH CT back to future availability, or removing that ticket type from GYG pricing. This can also be applicable to say a general Infant ticket type being applied to multiple mappings when the Infant customer type should be differentiated by language, pick-up location, etc.
• CT Capacity is More Restrictive. If a CT capacity is more restrictive than the availability capacity, chances are this can lead to an invalid availability error. For example, if a client only permits 2 Infants per availability, but the overall capacity reads 10, the API integration can’t distinguish that the X remaining spots are only allocated to Adult or Child, not Infant booking.
• Min/Max. Always check to see if the attempted booking exceeds the per booking maximum as set on their FareHarbor item. For example, if an end-customer attempts a booking of 10 passengers, but each Vehicle only accommodates up to 5 and they don’t allow split parties. The booking maximum is GYG should always reflect the most restrictive per booking maximum.

Yes, Expedia can pull from FareHarbor’s transportation module, including pickups, routes and instructions. It populates the FH transportation custom field accordingly; however, if a guest selects transportation but there was a match-up issue with FH, the Expedia customer’s selection will populate the FareHarbor booking comments. If the Expedia customer doesn’t select transportation info on the front-end, additional criteria appears blank.

Here’s a helpful resource on Expedia API Connectivity x Transportation.

Expedia rate expiration is not related to the FareHarbor API connection.

Each year, Expedia rates will expire and clients will need to manually enter their rates again to renew availability. This is a similar process to building out a price schedule in Viator and can be found in the rates section of the Expedia back-end. Clients will need to extend their rates into YEAR by manually entering them themselves. They can reach out to the Expedia support team with further instructions on this process.