# Step 3: Implement the Waitlists booking server You need to stand up a booking server to allow the Actions Center to make callbacks to create and update bookings on your behalf. - **The Reservations Waitlists implementation.** This is used when you participate in the Reservations Waitlists pilot program. This allows the Actions Center to retrieve wait estimates and create waitlist entries on behalf of the user. - **The Standard implementation.** This allows the Actions Center to create appointments, bookings, and reservations with you on behalf of the user. To implement a booking server for the Reservations End-to-End integration please refer to [Implement the booking server](https://developers.google.com/actions-center/verticals/reservations/waitlists/integration-steps/implement-booking-server). Refer to the [Partner Portal](https://developers.google.com/actions-center/verticals/reservations/waitlists/partner-portal/testing/booking-server-endpoint-and-credentials) 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](http://en.wikipedia.org/wiki/Representational_State_Transfer) 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 Actions Center sandbox environment. Only move to a production environment once the sandbox server is fully tested. ### Methods 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. | Waitlist implementation | |---| | [Waitlist service definition](https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/proto-interface). Download the proto service definition file. | | Method | HTTP Request | |---|---| | [HealthCheck](https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/healthcheck-method) | GET /v3/HealthCheck/ | | [BatchGetWaitEstimates](https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/batchgetwaitestimates-method) | POST /v3/BatchGetWaitEstimates/ | | [CreateWaitlistEntry](https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/createwaitlistentry-method) | POST /v3/CreateWaitlistEntry/ | | [GetWaitlistEntry](https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/getwaitlistentry-method) | POST /v3/GetWaitlistEntry/ | | [DeleteWaitlistEntry](https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/deletewaitlistentry-method) | POST /v3/DeleteWaitlistEntry/ | ### API resources #### Waitlist The following resources are used to implement waitlist-based booking: - [WaitEstimate](https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitestimate-definition): A wait estimate for a specific party size and merchant. - [WaitlistEntry](https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitlistentry-definition): A user's entry in the waitlist. ### Flow: create a waitlist entry This section covers how to create a booking for the Reservations Waitlists integration. ![Figure 2: Workflow to create a waitlist entry](https://developers.google.com/static/actions-center/images/waitlists/rest_api_v3_waitlist_flow.png) Figure 2: Workflow to create a waitlist entry When the user creates a waitlist entry, Google sends you the user's given name, surname, phone number, and email. The email is the same as the user's Google account and is treated as a unique identifier. From your point of view, this waitlist 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 waitlist entry appears identical to your merchants' entries that come from your waitlist system. ### 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](https://www.ssllabs.com/ssltest/). 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](https://partnerdash.google.com/apps/reservewithgoogle/configuration/booking-server). Passwords must be rotated every six months. > [!NOTE] > **Note:** You must set username and password for Sandbox and Production separately by using the [Environment switcher](https://developers.google.com/actions-center/verticals/reservations/waitlists/partner-portal/overview/environment-switcher). ### 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](https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-code-samples/node-js) - Java skeleton [java-maps-booking-rest-server-v3-skeleton](https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-code-samples//java) These servers have stubbed out REST methods. > [!NOTE] > **Note:** For Reservations Waitlists integration, change the REST methods to the required Reservations Waitlists methods. ## Requirements ### 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](https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/status-codes). - **Errors related to business logic** - Return HTTP status code set to `200` OK, 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. For the Reservations Waitlists integraton, business logic errors are captured in [Waitlist Business Logic Failure](https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitlistbusinesslogicfailure-definition) and they're returned in HTTP response. Business logic errors may be encountered when a resource is created, for instance when you handle the `CreateWaitlistEntry` method. Examples include, but are not limited to, the following: - `ABOVE_MAX_PARTY_SIZE` is used when the requested waitlist entry is over the merchant's maximum party size. - `MERCHANT_CLOSED` is used when the waitlist isn't open because the merchant is already closed. ### Idempotency 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: - `CreateWaitlistEntry` - `DeleteWaitlistEntry` For every request message except `DeleteWaitlistEntry`, 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. `DeleteWaitlistEntry` is uniquely identified by their waitlist entry IDs respectively, so no idempotency token is included in their requests. The following are some examples of how booking servers handle idempotency: - A successful `https://developers.google.com/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/createwaitlistentry-method` HTTP response includes the created waitlist entry ID. If the same `CreateWaitlistEntryRequest` is received a second time (with the same `idempotency_token`), then the same `CreateWaitlistEntryResponse` must be returned. No second waitlist entry is created and no error is returned. Note that if a `CreateWaitlistEntry` attempt fails and the same request is resent, your backend should retry in this case. The idempotency requirement applies to all methods that mutate state.