CreateBooking Ready

To complete the CreateBooking Ready milestone task, you need to successfully build and deliver the CreateBooking method. This method is called when a user attempts to create a booking. If a successful booking is created, the response includes a unique booking_id to refer to the booking for future requests or updates.

CreateBooking task requirements

• 10 successful CreateBooking responses with an error rate less than 10%.

CreateBooking basics

When a user initiates a booking, a CreateBooking request is sent to the partner Booking Server. The response to the request indicates either a successful booking or booking failure. If there is a booking failure, the response needs to include the business logic error for failure. For example, the slot has become unavailable or the slot has been already booked by the same user.

When a user creates a booking, Google sends you the user's given name, surname, phone number, and email. For more information, see Account matching and creation policy.

Note: Business logic errors must be returned in the CreateBookingResponse.booking_failure field, rather than through a non-200 HTTP response code.

Warning: Booking failures because of the unavailability of the slot are considered CreateBooking errors. Your integration can be disabled when there are many CreateBooking errors. High error rate for CreateBooking availability errors indicate that your BatchAvailabilityLookup slot click response doesn't accurately reflect real-time inventory.

Idempotency

Communication over the network isn't always reliable, and Google can retry HTTP requests if no response is received. For this reason, all methods that mutate state must be idempotent:

• CreateBooking
• UpdateBooking

For every request message, except UpdateBooking, idempotency tokens are included to uniquely identify the request. This lets you distinguish between a retried REST call, with the intent to create a single request and two separate requests. The respective booking entry IDs of the UpdateBooking help to uniquely identify them, so no idempotency token is included in their requests.

The following are some examples of how Booking Servers handle idempotency:

• A successful CreateBooking HTTP response includes the created booking. In some cases, payment is processed as part of the booking flow. If the same CreateBookingRequest is received a second time with the same idempotency_token, the same CreateBookingResponse must be returned. A second booking isn't created, and the user is charged exactly once, if applicable.

  Note: If a CreateBooking attempt fails and the same request is re-sent, your backend must retry the CreateBooking request.

The idempotency requirement applies to all methods that mutate state.