You need to stand up a booking server to allow Reserve with Google to make callbacks to create and update bookings on your behalf.
- The Standard implementation. This allows Reserve with Google to create appointments, bookings, and reservations with you on behalf of the user.
- The Waitlist implementation. This is used when you participate in the waitlist pilot program. This allows Reserve with Google to retrieve wait estimates and create waitlist entries on behalf of the user. To implement a booking server for Waitlist please refer to Implement Waitlist Booking Server.
Refer to the Partner Portal documentation to learn how to configure the connection to your sandbox and production booking servers.
Implement a REST API interface
Implement an API interface based on REST This allows Google to send booking server requests over HTTP.
To start, set up a development or sandbox booking server that can be connected to the Reserve with Google sandbox environment. Only move to a production environment once the sandbox server is fully tested.
For each type of booking server, a different set of API methods are required on your end. Optionally, you can download the service definition in proto format to get started with the API implementation. The following tables show the methods for each implementation and include links to the service proto formats.
|Standard service definition Download the proto service definition file.|
The following resource types are used in the standard implementation:
Flow: create a booking
This section covers how to create a booking for the standard implementation.
When a user creates a booking, Google sends you the user's given name, surname, phone number, and email. From your point of view, this booking needs to be treated as a guest checkout, because Reserve with Google can't look up the user's account in your system. Make sure the final booking appears identical to your merchants' bookings that come from your booking system. Guest checkout and alternate emails are supported by default in the Dining and Beauty verticals for non-paid bookings.
Security and Authentication
All communication to your booking server happens over HTTPS, so it's essential that your server has a valid TLS certificate that matches its DNS name. To help set up your server, we recommend the use of a freely available SSL/TLS verification tool, such as Qualys' SSL Server Test.
All requests Google will make to your booking server will be authenticated using HTTP basic authentication. The basic authentication credentials (username and password) for your booking server can be entered in the Booking Server Configuration page within the Partner Portal. Passwords must be rotated every six months.
Sample Skeleton Implementations
To get started, check out the following sample skeletons of a booking server written for Node.js and Java frameworks:
- Node.js skeleton js-maps-booking-rest-server-v3-skeleton
- Java skeleton java-maps-booking-rest-server-v3-skeleton
These servers have stubbed out REST methods.
HTTP errors and business logic errors
When your backend handles HTTP requests, two types of errors may occur.
- Errors related to infrastructure or incorrect data
- Return these errors to the client with standard HTTP error codes. See the full HTTP status code list.
- Errors related to business logic
- Return HTTP status code set to
200OK, and specify the business logic failure in the response body. The types of business logic errors you can encounter are different for the different types of server implementations.
- Return HTTP status code set to
For the Standard implementation, the possible business logic errors are
Booking Failure and they're returned in the HTTP response. Business
logic errors may be encountered when a resource is created or updated. For
instance, when you handle the methods
UpdatingBooking. Examples include, but aren't limited to, the
SLOT_UNAVAILABLEis used if the requested slot is no longer available.
PAYMENT_ERROR_CARD_TYPE_REJECTEDis used if the provided credit card type is not accepted.
Communication over the network is not always reliable and Google may retry HTTP requests if no response is received. For this reason, all methods that mutate state must be idempotent:
For every request message except
UpdateBooking, idempotency tokens are included to uniquely
identify the request. This allows you to distinguish between a retried REST
call, with the intent to create a single request, and two separate requests.
UpdateBooking is uniquely
identified by their booking entry IDs respectively, so no
idempotency token is included in their requests.
The following are some examples of how booking servers handle idempotency:
CreateBookingHTTP response includes the created booking. In some cases, payment is processed as part of the booking flow. If the exact same
CreateBookingRequestis received a second time (with the same
idempotency_token), then the same
CreateBookingResponsemust be returned. No second booking is created, and the user is charged exactly once, if applicable.
Note that if a
CreateBookingattempt fails and the same request is resent, your backend should retry it in this case.
The idempotency requirement applies to all methods that mutate state.