Stay organized with collections
Save and categorize content based on your preferences.
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.
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.
The idempotency requirement applies to all methods that mutate state.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-07-22 UTC."],[],[],null,["# CreateBooking Ready\n\nTo complete the `CreateBooking` Ready milestone task, you need to successfully\nbuild and deliver the `CreateBooking` method. This method is called when a user\nattempts to create a booking. If a successful booking is created, the response\nincludes a unique `booking_id` to refer to the booking for future requests or\nupdates.\n\nCreateBooking task requirements\n-------------------------------\n\n- 10 successful `CreateBooking` responses with an error rate less than 10%.\n\nCreateBooking basics\n--------------------\n\nWhen a user initiates a booking, a `CreateBooking` request is sent to the\npartner Booking Server. The response to the request indicates either a\nsuccessful booking or booking failure. If there is a booking failure, the\nresponse needs to include the business logic error for failure. For example, the\nslot has become unavailable or the slot has been already booked by the same\nuser.\n\nWhen a user creates a booking, Google sends you the user's given name, surname,\nphone number, and email. For more information, see\n[Account matching and creation policy](/actions-center/verticals/reservations/e2e/policies/platform-policies#account_matching_and_creation_policy).\n| **Note:** Business logic errors must be returned in the `CreateBookingResponse.booking_failure` field, rather than through a non-200 HTTP response code.\n| **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.\n\n### Idempotency\n\nCommunication over the network isn't always reliable, and Google can retry HTTP\nrequests if no response is received. For this reason, all methods that mutate\nstate must be idempotent:\n\n- `CreateBooking`\n- `UpdateBooking`\n\nFor every request message, except `UpdateBooking`, idempotency tokens are\nincluded to uniquely identify the request. This lets you distinguish between a\nretried REST call, with the intent to create a single request and two separate\nrequests. The respective booking entry IDs of the `UpdateBooking` help to\nuniquely identify them, so no idempotency token is included in their requests.\n\nThe following are some examples of how Booking Servers handle idempotency:\n\n- A successful\n [`CreateBooking`](/actions-center/verticals/reservations/e2e/reference/booking-server-api-rest/e2e-methods/createbooking-method)\n HTTP response includes the created booking. In some cases, payment is processed\n as part of the booking flow. If the same `CreateBookingRequest` is received a\n second time with the same `idempotency_token`, the same `CreateBookingResponse`\n must be returned. A second booking isn't created, and\n the user is charged exactly once, if applicable.\n\n | **Note:** If a `CreateBooking` attempt fails and the same request is re-sent, your backend must retry the `CreateBooking` request.\n\nThe idempotency requirement applies to all methods that mutate state."]]