Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Para concluir a tarefa do marco CreateBooking Pronto, você precisa criar e entregar o método CreateBooking. Esse método é chamado quando um usuário
tenta criar uma reserva. Se uma reserva for criada, a resposta vai incluir um booking_id exclusivo para se referir à reserva em solicitações ou atualizações futuras.
Requisitos da tarefa CreateBooking
10 respostas CreateBooking bem-sucedidas com uma taxa de erro inferior a 10%.
Conceitos básicos do CreateBooking
Quando um usuário inicia uma reserva, uma solicitação CreateBooking é enviada ao servidor de reservas do parceiro. A resposta à solicitação indica uma reserva
bem-sucedida ou uma falha. Se houver uma falha no agendamento, a resposta precisará incluir o erro de lógica de negócios. Por exemplo, o espaço ficou indisponível ou já foi reservado pelo mesmo usuário.
A comunicação pela rede nem sempre é confiável, e o Google pode repetir solicitações HTTP se nenhuma resposta for recebida. Por isso, todos os métodos que modificam o estado precisam ser idempotentes:
CreateBooking
UpdateBooking
Para cada mensagem de solicitação, exceto UpdateBooking, os tokens de idempotência são incluídos para identificar a solicitação de maneira exclusiva. Assim, é possível distinguir entre uma chamada REST repetida, com a intenção de criar apenas uma solicitação, e duas solicitações separadas. Os respectivos IDs de entrada de agendamento do UpdateBooking ajudam a identificá-los de forma exclusiva. Portanto, nenhum token de idempotência é incluído nas solicitações.
Confira alguns exemplos de como os servidores de agendamento lidam com a idempotência:
Uma resposta HTTP CreateBooking bem-sucedida inclui o agendamento criado. Em alguns casos, o pagamento é processado
como parte do fluxo de reserva. Se o mesmo CreateBookingRequest for recebido uma segunda vez com o mesmo idempotency_token, o mesmo CreateBookingResponse precisará ser retornado. Um segundo agendamento não será criado, e
o usuário será cobrado apenas uma vez, se aplicável.
CreateBooking
O requisito de idempotência se aplica a todos os métodos que modificam o estado.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]