Things-To-Do Integration Tips and Gotchas

In 2018, Reserve with Google started to support partners in the Things-To-Do vertical, including museums, attractions, tours, activities and events.

The high level integration process is the same as other verticals, as outlined in the end-to-end integration guide. The main difference is that Order-based API specification should be used for the booking server piece.

This guide is a collection of tips on how to apply the Maps Booking API to some common scenarios in TTD integrations.

How to specify entrance tickets for attractions?

By default, an availability slot represents the time range that the user needs to be at the merchant. However, for admission/entrance tickets, users typically can go to the venue any time during the time range. Furthermore, users are able to make bookings even when the start time has passed. For this use case:

  • In the service SchedulingRules, set admission_policy to be TIME_FLEXIBLE
  • Set min_booking_buffer_before_end_time as a positive value to enable booking after slot start.
  • The availability time slots should be set as the time ranges when the user can visit the venue using the ticket, typically, it's the opening hour of the venue. If you don't have opening hour data for the venue, please set the time range to be long enough (up to 24 hours) to cover the venue hours (e.g., 12am to 12am), but make sure that the start and end time works correctly with your booking server as they are used to identify the availability slot during booking.

How to represent multiday passes or tickets that can be used for multiple days?

In the availability feed specs, the time range, including begin_sec and end_sec, is required and the duration cannot be longer than 24 hours. However, this doesn't mean that the duration that the ticket is valid for needs to be within 24 hours. The slot duration will not be shown to users as long as the service scheduling rules are configured properly as follows:

  • The service scheduling rules should follow the entrance tickets specification above.
  • On every day that the venue is open, there should be an entry in the availability feed corresponding to tickets that start on this date.
  • Please make sure the valid duration of the ticket is made clear in either of the following:
    1. (preferred if possible) ticket type description if, say, 1-day pass and 3-day pass are both available as different ticket types for the same product, or
    2. service name or description if the duration applies to all tickets of this service.
  • Whichever end_sec value you choose to set (must be in (begin_sec and, start_sec+24*3600]), make sure that the time range specified in the availability feed is consistent with how your booking server validates availability for CheckOrderFulfillability and CreateOrder requests.

How to represent tickets or activities with a start time but with unknown end time?

In the availability feed specs, the time range, including begin_sec and end_sec, is required. However, the slot duration will not be shown to users as long as the service scheduling rules are configured properly as follows:

  • Please set admission_policy to be TIMED_ENTRY_WITH_FLEXIBLE_DURATION in the service scheduling rules.
  • Whichever end_sec value you choose to set (must be in (begin_sec, start_sec+24*3600]), make sure that the time range specified in the availability feed is consistent with how your booking server validates availability for CheckOrderFulfillability and CreateOrder requests.

How to represent dynamic prices?

  • If the ticket prices of a service change over time, please use feed update or real time API call to update the service.
  • If the ticket price differs based on time slots, please use slot level ticket types. For example, if the price of an adult ticket of a service is different on weekdays and on weekends, define two ticket types at the service level: {adult_weekday, adult_weekend}. The two ticket types can have the same description (e.g., "adult") but different prices. Then at the slot level, set the ticket_type_id to be the subset of ticket types that are eligible for this slot.

What to include in the service description?

  • Please send the text in HTML for structured service description. We support a limited set of tags--check the specs. The following general structure is recommended:
  • Start the description with a summary of the activity. Since the first paragraph of the description may be used to show an excerpt of the activity, the best practice is to exclude any header tags or bullets in the first paragraph.
  • Follow by sections such as highlights, itinery, includes, excludes, and important pre-purchase information about the activitiy.
  • Include the cancellation policy as the last section.