1. When a Google user leases an availability slot, does Google require that this availability slot be reserved until the user makes a decision or the lease expiration time has past?

    It is preferable to enforce the lease, i.e. prevent other users from "stealing" the slot while contact information data is entered and payments are processed. If you backend does not support leasing, we expect you, at the very least, to verify that the slot is still bookable.

  2. What booking fields may be requested to be updated on a booking update coming from Google?

    We only expect start_time, duration and appointment state to be subject to update request. For example, rescheduling to a different slot or cancelling an appointment. For any other changes, the booking should be canceled and rebooked.

  3. Will deleting a merchant delete all of its associated services and availability slots? Will deleting a service delete all of its associated availability slots?

    Deleting a merchant or service will automatically disable the sub-levels in our system. However, they will still be visible via the API. In the future we may add support for the concurrent deletion of sub-levels.

  4. Is sending real-time booking updates from our system required? If so, can this be handled by incremental feed updates (like availability)?

    Real-time booking updates are required via the use of Booking Notification API. This ensures an optimal user experience. If a merchant has to cancel or update an appointment, sending these updates allows us to notify the user. The main scenarios we envision for this are cancellation and rescheduling. Incremental feed updates can only be used for inventory updates, but not individual user booking updates.

  5. Does the UpdateBookingRequest booking contain the whole booking from CreateBookingResponse or only updated fields? For example, for a booking cancellation, FieldMask Path="status". Booking object only has Booking.status = 'BookingStatus.Canceled'

    It contains a mask containing the updated fields, and the whole booking from CreateBookingResponse.

  6. Does the UpdateBookingResponse need to complete (constructed if partial booking from UpdateBookingRequest) on return?

    We have the following expectations for the return value from an update booking:

    • It contains the booking ID
    • All fields that were updated reflect the new value
  7. In the create lease request, is there a way to get the resources (mainly the employee id)?

    The resources submessage is used to specify the staff or room selected by the user.

  8. What response time limits should our gRPC server support for the Lease & Booking API calls?

    The Lease and Booking calls are performed in sync, while the user is booking, therefore latency is very important here. Please aim for sub-second latency. Your server should be able to handle 5 QPS with sub-second latency at least 95% of the time.

  9. Who generates the booking id during a new booking in CreateBooking API call? Does it need to correlate to the lease id?

    Please generate a booking ID on your end. We treat it as an opaque identifier. It does not need to correlate to the lease id.

  10. What is the format and representation of timestamps within gRPC calls?

    All timestamps should be in UNIX time format in UTC.

  11. What should happen if we get a quota exceeded error?

    To handle such a message, retry with exponential backoff. If the quotas get reached regularly while doing ReplaceServiceAvailability, it is recommended that you switch to batch replace for Availability to reduce the number of API calls.

  12. When batch updating availability, how many slots should be included in a single API call?

    We recommend aiming for 100-1000 availability slots per call.

    If you spin off many threads, be sure to correctly implement exponential backoff in case you get throttled.

  13. What bookings should be returned in the ListBooking gRPC call?

    This should return all upcoming bookings for the user being requested. It doesn't need to return bookings from the past.

  14. Do you have a version of the API for accessing the sandbox environment?

    Yes. You will need to enable Maps Booking API (dev) in your Google Cloud project, which is only accessable to whitelisted Google Accounts. We whitelist your developer account automatically during the initial setup, but if you have trouble finding this API, confirm with Google that the correct Google account is whitelisted. Then all you need to do is change the endpoint of your API calls to https://partnerdev-mapsbooking.sandbox.googleapis.com/.