Overview and Eligibility

The following describes the details of the Actions Center Reservations End-to-End integration process.

Integration

Follow the standard high-level integration process outlined in the end-to-end integration guide.

Onboarding overview for the Reservations End-to-End integration.
Onboarding overview for the Reservations End-to-End integration.

Key Reservations End-to-End Guidance

The following points overview are examples and tutorial covering key features that are required by the Reservations End-to-End integration:

  • Feeds:
    • The Reservations End-to-End integration requires Merchant, Service and Availability feeds to be sent daily via SFTP.
    • Within the merchant feeds - it is important that the name, address, phone number, and URL of each location matches closely with the Google listing for matching to be successful.
    • Merchants in Reservations End-to-End can only have one service used for displaying availability.
    • It is recommended to set the service_id same static value across all your merchants if reservations is the only service provided by your merchants. If applicable, specify the scheduling_rules and cancellation_policy in the services feed.
    • The central distinction of Reservations End-to-End inventory is the need to define party_size for all availability - for more information, refer to these guides:
  • Booking Server:
    • The booking server acts as Google's entrypoint for confirming availability as well as creating, updating, deleting and modifying bookings made via Google surfaces.
    • To ensure a positive user experience, we require your response to each of these requests to fall within our error rate and latency thresholds.
    • For request / response examples, please refer to these guides:
  • Real-time updates:
    • While not required, real-time-updates can enable you to asynchronously send us updates on booking cancellations or availability changes before a user attempts to access your availability - this results in fewer overall unbookable slots being shown to users in the event that BatchAvailabilityLookup fails. For more information, please review our documentation on Structuring Real-Time Updates.
  • Additional notes:
    • If your Availability feed file (after compression) are larger than 200MB, sharding is required to split the feed in less than 200MB (compressed) files.
    • Merchants in Reservations End-to-End can only have one service

Additional Reservations End-to-End Features

These are features to consider while completing your Reservations End-to-End integration. None of these are required, but many will be necessary to make sure the Actions Center follows your company's business logic when serving your inventory: