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.

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:
  - Reservations End-to-End Availability Guide
  - Sample Reservations End-to-End Feeds
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:
  - Standard Integration: Implement the standard booking server integration.
  - Waitlist Integration: Implement the waitlist booking server integration.
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: