Booking Server Ready

You need a Booking Server to let the Actions Center make callbacks to create and update bookings on your behalf. This lets the Actions Center create appointments, bookings, and reservations with you on behalf of the user.

To learn how to configure the connection to your Sandbox and Production Booking Servers, see Configure Booking Server Credentials.

Complete the following Booking Server Ready tasks before you move to Real-Time Updates:

Each task is marked completed and turns green when you send accurate, real-time inventory details to Booking Server requests through the Sandbox booking flow. Booking Server milestones are analyzed over a period of 14 days.

Implement a REST API interface

Implement an API interface based on REST. This lets Google send Booking Server requests over HTTPS.

To implement an API interface, set up a development or Sandbox Booking Server that connects to the Actions Center Sandbox environment. Move to a Production environment only after the Sandbox server is fully tested.

All Google's Booking Server requests are relative to the Booking Server URL set on the Booking Server page. For example, if your URL is set to api.example.com/google, then all HealthCheck requests are sent to api.example.com/google/v3/HealthCheck.

Make sure that the correct Booking Server endpoint is configured for both the Sandbox and Production environments with the environment switcher.

Security and authentication

All communication to your Booking Server happens over HTTPS using basic authentication. To help set up your server, we recommend the use of a publicly available SSL or TLS verification tool, such as Qualys' SSL server test.

All requests that Google makes to your Booking Server are authenticated with HTTPS basic authentication. You can enter your Booking Server's basic authentication information, password, and username on the Actions Center's Booking Server configuration page. Credentials must be changed every six months.

Build your Booking Server

The Booking Server determines how the integration communicates with your system, and makes or updates bookings. To configure the connection to your Sandbox and Production Booking Servers, see Configure Booking Server Credentials.

Every response that your Booking Server makes to a request from Reserve with Google is expected to contain accurate, real-time inventory details. The following table shows the methods for each implementation, and includes links to the service protocol formats:

Method Definition Response HTTP request
BatchAvailabilityLookup page load

When a user clicks Reserve a Table for your merchant, the BatchAvailabilityLookup request is called on page load.

The payload contains numerous slots that are based on your latest Feed uploads, which Reserve with Google considers available.

 The response must include every slot request and the current availability of the slot. This prevents any unavailable slots from displaying. POST /v3/BatchAvailabilityLookup/
BatchAvailabilityLookup slot click When a user is presented with available slots for booking and clicks a slot, the BatchAvailabilityLookup request is called for slot click. The response must represent the current, actual availability of the slot. If it's booked out before the slot click, return the response that it's not available. POST /v3/BatchAvailabilityLookup/
CreateBooking When a user confirms they want to book a selected time slot in the booking modal, the CreateBooking request is sent.

The response must represent the success or failure of the booking.

If the booking is failed, you need to return the specific reason for the failure. For example, the slot was booked out before the CreateBooking response was called.

If a successful booking is created, the response includes a unique booking_id to refer to the booking in any future requests or updates.

 POST /v3/CreateBooking/
UpdateBooking After a booking is made through Reserve with Google, a user can choose to modify their booking. When the user updates their reservation or cancels it, a UpdateBooking request is sent. Like the CreateBooking response, your response to UpdateBooking must represent the success of the booking or return the specific reason for a failure. POST /v3/UpdateBooking/
HealthCheck The Actions Center makes regular calls to your Booking Server to confirm your infrastructure is active and running.

Use HTTP status code to indicate the serving status of your server. Return an HTTP status code 200 if the server is active and running successfully.

To indicate an error or to temporarily take your integration offline, return the appropriate non-2xx HTTP status code.

 GET /v3/HealthCheck/

Sandbox booking flow

To view the Sandbox booking flow, go to the Actions Center Inventory view. The RwG - E2E column of the Inventory view displays a Live (in Sandbox) link to the Sandbox booking flow for Sandbox merchants that are matched and have future availability.

The following are the actions in the booking flow:

  • When you click the RwG - E2E link, it triggers a BatchAvailabilityLookup request on page load and presents the known availability of the merchant.
  • When you click a reservation time, it triggers the BatchAvailabilityLookup on slot click request and presents the booking modal.
  • Complete a booking with the booking modal to send the CreateBooking request.
  • After you complete a booking in the Sandbox environment, the account used to create the booking receives an email confirmation with the booking details.
  • To trigger the UpdateBooking method, change or cancel the booking from the email.

HealthCheck

Make sure to implement the HealthCheck method in Sandbox and Production. This method returns your Booking Server health status. It lets Google continuously monitor the serving state of your Booking Server.

Request: None

Return value: None

Use HTTP status code to indicate the serving status of your server.

If the server is active and runs successfully, return an HTTP status code 200, or to indicate an error return one of HTTP status code.