The following describes the details of the Reserve with Google integration process that are unique to the dining vertical.
Integration
Follow the standard high-level integration process outlined in the end-to-end integration guide.
Key Dining Guidance
The following are examples and tutorial covering features that are required by the dining integration:
- Feeds:
- Service Id
- It is recommended to set the
service_id
same static value across all your merchants if dining reservations is the only service provided by your merchants. - Party Size
- The central distinction of dining inventory is the need to define party_size for all availability
- 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 dining can only have one service
- Booking Server:
- Standard Integration: Implement the standard booking server integration.
- Waitlist Integration: Implement the waitlist booking server integration.
- Real-time updates:
- Implement the Structuring Real-Time Updates.
Optional Dining Features
Below are a list of features that are compatible with the dining integration. None of these are required, but many will be necessary to make sure Reserve with Google follows your company’s business logic when serving your inventory:
- Reservations Requiring Restaurant Approval (Async Booking)
- Adding Dining Sections
- Adding Dining Special Request Box
- Adding Cancellation Windows
- Waitlists
- No-Show Fees
- Deposits
- Setting a minimum advanced booking time
- Adding merchant specific terms