Best practices

The following best practices apply to the Actions Center Reservations Waitlists integration and can be leveraged to avoid usability and performance issues. Low data quality might lead to inventory takedown.

Feeds

• If a service doesn't have a set length, set duration_sec in the Availability feed to one of the following:
  • The number of seconds it takes to perform the service in a reasonable manner.

  • The average number of seconds required to complete the service.

    Note: If a length of 0 is submitted in the feed, our system counts that availability slot as invalid and doesn't show it on the Actions Center.
• Make the Category field input in the merchant's feed is specific. For example, a restaurant might submit a specific type, such as French or Japanese. For details, see Place types for potential category values.

• Set merchant-specific terms of service in the Terms field of the Merchant feed so that the following note appears below the Book button:

  By continuing, you agree to <merchant>'s Terms of Service.

  In this case, "Terms of Service" is a link that, when clicked, displays the text set in the terms text field.

• Compress your feeds using gzip

Booking Server

To optimize your integration of the Maps Booking API, do the following:

• Always use UNIX timestamps in UTC format.
• Generate a unique booking ID when a new booking in the CreateBooking API is called.

Real-time updates

To ensure the best user experience during the booking process, do the following:

• For a standard implementation, use the BookingNotifications API to change the start time, duration, and booking state, such as cancellation or no-show, of an appointment.
• Upon any change on the Actions Center booking from your side, always send real-time booking updates from the system with the BookingNotification API in real-time so that the data doesn't become stale on the Actions Center side. For example, you can cancel, reschedule, or update a booking from your system in the Actions Center.
• For every booking update from UpdateBookingRequest, make sure that the UpdateBookingResponse value contains the booking ID and that all updated fields must reflect the new value.
• If Inventory RTU are implemented
  • Only update availability in batches of 100-1000 slots per API call.
  • Use *Restrict (such as startTimeRestrict) fields to narrow the edit target, reduce payload size and avoid re-sending too much unchanged data.
  • If you spin off several threads, implement an exponential backoff to prevent throttle errors. If you don't implement an exponential backoff correctly, you might get a RESOURCE_EXHAUSTED quota error. You can retry the exponential backoff to handle them, but, if you find that your server often reaches quotas when you run ReplaceServiceAvailability, configure your server to batch replace for availability. This solution prevents quota errors because it reduces the number of API calls your serve has to make.
• Set your API call response time limits to less than one second. Ensure that your server can handle five queries per second (QPS) with sub-second latency at least 95% of the time.