The following describes the details of the Reserve with Google integration process that are unique to the dining vertical.
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:
- Service Id
- It is recommended to set the service_id to '1000' 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
- Service Id
- The added complexity of sharding your feeds is usually unnecessary for dining integrations as the availability data tends to be more compact. Avoid sharding unless your availability feed will be larger than 200 MB (compressed).
- Merchants in dining can only have one service
- Implement the standard booking server integration
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
- No-Show Fees
- Setting a minimum advanced booking time
- Adding merchant specific terms
- Recurrences: Modeling slot as repeating events in a day