CreateBooking 준비 완료 마일스톤 작업을 완료하려면 CreateBooking 메서드를 성공적으로 빌드하고 제공해야 합니다. 이 메서드는 사용자가 예약을 생성하려고 할 때 호출됩니다. 예약이 성공적으로 생성되면 향후 요청이나 업데이트에서 예약을 참조할 수 있는 고유한 booking_id가 응답에 포함됩니다.
CreateBooking 작업 요구사항
오류율이 10% 미만인 CreateBooking 응답 10개가 성공했습니다.
CreateBooking 기본사항
사용자가 예약을 시작하면 CreateBooking 요청이 파트너 예약 서버로 전송됩니다. 요청에 대한 응답은 예약 성공 또는 예약 실패를 나타냅니다. 예약 실패가 있는 경우 응답에 실패에 대한 비즈니스 로직 오류가 포함되어야 합니다. 예를 들어 시간대를 사용할 수 없게 되었거나 동일한 사용자가 이미 시간대를 예약한 경우입니다.
사용자가 예약을 만들면 Google에서 사용자의 이름, 성, 전화번호, 이메일을
전송합니다. 자세한 내용은 계정 일치 및 생성 정책을 참고하세요.
멱등성
네트워크를 통한 통신이 항상 신뢰할 수 있는 것은 아니며 응답을 받지 못하면 Google에서 HTTP 요청을 다시 시도할 수 있습니다. 따라서 상태를 변경하는 모든 메서드는
멱등성을 갖춰야 합니다.
CreateBooking
UpdateBooking
UpdateBooking를 제외한 모든 요청 메시지에 멱등성 토큰이 포함되어 요청을 고유하게 식별합니다. 이렇게 하면 단일 요청을 만드는 인텐트와 두 개의 개별 요청을 사용하여 재시도된 REST 호출을 구분할 수 있습니다. UpdateBooking의 각 예약 항목 ID는 UpdateBooking를 고유하게 식별하는 데 도움이 되므로 요청에 멱등성 토큰이 포함되지 않습니다.
다음은 예약 서버가 멱등성을 처리하는 방법의 몇 가지 예입니다.
성공한 CreateBooking HTTP 응답에는 생성된 예약이 포함됩니다. 경우에 따라 결제가 예약 과정의 일부로 처리됩니다. 동일한 CreateBookingRequest가 동일한 idempotency_token와 함께 두 번째로 수신되면 동일한 CreateBookingResponse가 반환되어야 합니다. 두 번째 예약이 생성되지 않으며 해당하는 경우 사용자에게 정확히 한 번만 청구됩니다.
[null,null,["최종 업데이트: 2025-07-26(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."]]
