Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Os parceiros que usam o programa de listas de espera de reservas precisam concluir a configuração da conta antes de começar. No entanto, algumas etapas do guia geral não são necessárias para
usar o recurso de lista de espera. As diretrizes desta página explicam quais etapas
se aplicam a parceiros interessados em usar o recurso de lista de espera no Reservar com
o Google. Sugerimos a leitura da visão geral antes de seguir
as etapas de integração.
Processo de lançamento
A Figura 1 descreve o processo para lançar os comerciantes que usam listas de espera
no Centro de ações.
Figura 1: etapas de integração de alto nível
No geral, os principais fluxos de dados entre você (o parceiro) e o Google são
mostrados na Figura 2:
Figura 2: diagrama de fluxo de dados de integração
Diretrizes para todos os parceiros da lista de espera de reservas
Lembre-se do seguinte ao implementar o recurso de listas de espera para reservas:
O serviço de cada comerciante que usa a lista de espera de reservas precisa ter o campo waitlist_rules preenchido.
É necessário usar o mesmo serviço para a lista de espera e a reserva. Em outras palavras, se o restaurante também permite reservas, basta adicionar os metadados relacionados à lista de espera ao serviço para reserva.
O envio de atualizações por SMS é necessário para a implementação da lista de espera nos
seguintes casos:
Para confirmar que o usuário entrou na lista de espera.
Notificar o usuário de que a mesa está pronta.
Para notificar o usuário de que a entrada na lista de espera foi cancelada.
As mensagens SMS precisam conter um link para uma página em que os usuários possam conferir o
status da lista de espera.
Os comerciantes que utilizam somente esse recurso não precisam enviar feeds de disponibilidade ao Centro de ações.
Seu servidor de agendamento precisa implementar todas as etapas específicas da lista de espera
mencionadas em
Implementar o servidor de agendamento. Os parceiros que aceitam reservas e listas de espera podem adicionar os novos métodos ao servidor de agendamento.
O Actions Center executa um conjunto de
casos de teste para os métodos da lista de espera no servidor de agendamento.
Confira a seguir casos extremos comuns em uma integração de listas de espera de reservas e as soluções
preferidas para eles.
Se alguns tamanhos de grupo (mas não todos) não aceitarem novas adições à lista de espera
porque atualmente não há tempo de espera para eles, é preferível retornar
WaitEstimates para todos os grupos na
resposta BatchGetWaitEstimates e permitir que os usuários entrem na
lista de espera desses grupos sem tempo de espera. Retorne um WaitLength com
0 parties_ahead_count e/ou com um estimated_seat_time_range com 0
start_seconds e com 0 end_seconds para os party_sizes
sem espera
Caso um ou mais grupos não aceitem essas inclusões porque o tempo de espera ficou muito longo, omita
WaitEstimates para eles na resposta BatchGetWaitEstimates.
Essas abordagens são preferenciais. Os usuários podem tomar decisões próprias, embora a lista de espera do comerciante não esteja totalmente aberta em alguns casos.
Diretrizes para parceiros que usam apenas listas de espera para reservas
Lembre-se do seguinte se o servidor de agendamento for usado somente para
listas de espera:
Os parceiros que usam apenas esse recurso não enviam feeds de disponibilidade ao Reservar com o Google.
Os parceiros que usam apenas a lista de espera não implementam os métodos de reserva no servidor de agendamento. Em vez disso, implemente o servidor de agendamento com as instruções para a implementação da lista de espera.
Os parceiros que usam apenas esse recurso não fazem chamadas de API para o Google. Isso significa que
os parceiros que usam apenas a lista de espera não precisam configurar um projeto na nuvem nem fornecer um
endereço de e-mail do desenvolvedor. Não é necessário fazer as
atualizações em tempo real da API. No entanto, os feeds do comerciante e de serviços ainda precisam ser enviados ao Centro de ações.
Diretrizes para parceiros em que os comerciantes precisam
aceitar/recusar manualmente adições à lista de espera
Se os comerciantes precisarem aceitar ou recusar de forma manual novas
adições à lista de espera do Google, serão necessárias etapas adicionais:
Defina o waitlist_confirmation_mode como
WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS em
wait_estimate para tamanhos de grupo que exigem confirmação
manual. Isso precisa ser definido em
BatchGetWaitEstimateResponse e
GetWaitlistEntryResponse.
As entradas da lista de espera que foram solicitadas pelo usuário, mas ainda não
foram aceitas pelo comerciante, devem estar no estado
PENDING_MERCHANT_CONFIRMATION.
Casos de teste de listas de espera de reservas
O Google testa os seguintes casos de uso para garantir a funcionalidade dos
métodos da lista de espera na implementação do servidor de agendamento. O Google também testa e
monitora a latência. Todos esses testes precisam ser aprovados antes do lançamento.
Recuperação de WaitEstimate
As estimativas de espera são retornadas para cada tamanho de grupo solicitado em uma
BatchGetWaitEstimatesRequest.
No caso de grupos em que o comerciante pode aceitar ou recusar
novas adições à lista de espera, defina waitlist_confirmation_mode como
WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS.
Criação de entradas da lista de espera
Uma entrada da lista de espera pode ser criada diretamente de uma
solicitação CreateWaitlistEntry.
Se essa operação falhar, um erro de lógica de negócios será exibido na
resposta.
Se uma tentativa de CreateWaitlistEntry for bem-sucedida, a mesma resposta
será retornada quando a mesma CreateWaitlistEntry for recebida
novamente.
Se uma tentativa de CreateWaitlistEntry falhar, o servidor tentará de novo
quando a mesma CreateWaitlistEntry for recebida novamente.
As entradas da lista de espera são exibidas na interface do comerciante.
As chamadas para GetWaitlistEntry retornam a entrada da lista de espera
criada.
Estados e carimbos de data/hora das entradas da lista de espera
Verifique se cada estado é retornado corretamente na entrada da lista de espera das
respostas de GetWaitlistEntry.
Verifique se os carimbos de data/hora dos estados foram definidos no campo de carimbo de data/hora
apropriado da entrada na lista de espera nas respostas de GetWaitlistEntry.
Exclusão de entradas da lista de espera
É possível remover as entradas da lista de espera. A resposta a uma exclusão
bem-sucedida precisa ser o proto vazio {}.
[[["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."],[[["\u003cp\u003eThis guide explains the integration process for Reserve with Google's Waitlist feature, specifically designed for partners already familiar with Reservations.\u003c/p\u003e\n"],["\u003cp\u003ePartners need to implement waitlist-specific steps in their booking server and ensure it passes Google's test cases before launching.\u003c/p\u003e\n"],["\u003cp\u003eSMS updates for confirmations, table readiness, and cancellations are mandatory, including a link for users to check their waitlist status.\u003c/p\u003e\n"],["\u003cp\u003eIntegration typically requires 12-14 weeks with dedicated technical resources, and partners should be prepared for common edge cases and merchant opt-out scenarios.\u003c/p\u003e\n"],["\u003cp\u003eWhile Reservations partners need to add waitlist metadata to existing services, Waitlist-only partners don't need to provide availability feeds or implement reservation methods.\u003c/p\u003e\n"]]],["Partners in the Reservations Waitlists program must complete account setup. Key actions include populating `waitlist_rules` in the service feed, implementing a booking server with waitlist-specific steps, and sending SMS updates for waitlist confirmations, table readiness, and cancellations. Waitlist-only merchants do not require availability feeds or reservation methods. Manual accept/reject requires setting `waitlist_confirmation_mode`. Google tests wait estimate retrieval, waitlist entry creation/deletion, status reporting and opt out responses, all of which must pass prior to launch.\n"],null,["# Overview\n\n| **Note:** This section is only relevant for partners completing Reservations Waitlists integration.\n\nPartners participating in the Reservations Waitlists program must complete the account\n[Setup](/actions-center/verticals/reservations/waitlists/integration-steps/setup) before\nthey begin. However, some steps in the general guide aren't necessary for\nuse of the waitlist feature. The guidelines on this page explain what steps\napply to partners interested in using the waitlist feature on Reserve with\nGoogle. We suggest that you read through this overview before going through\nthe integration steps.\n\nLaunch process\n--------------\n\nFigure 1 outlines the process to launch your waitlist-enabled merchants\non the Actions Center.\n| **Note:** Integration typically takes 12-14 weeks with dedicated technical resources.\n**Figure 1:** High-level integration steps\n\nOverall, the major data flows between you (the Partner) and Google are\ncaptured in Figure 2:\n**Figure 2:** Integration data flow diagram\n\nGuidelines for all Reservations Waitlists partners\n--------------------------------------------------\n\nKeep the following in mind as you implement the Reservations Waitlists feature:\n\n- The service for every Reservations Waitlists merchant must have [`waitlist_rules` populated](/actions-center/verticals/reservations/waitlists/reference/feeds/services-feed).\n - You must use the same service for both waitlist and reservation. In other words, if your restaurant also allows reservations, just add the waitlist related metadata to the service for reservation.\n- Sending out SMS updates is required for the waitlist implementation in the following cases:\n - To confirm the user has successfully joined the waitlist.\n - To notify the user that their table is ready.\n - To notify the user that their waitlist entry has been cancelled.\n- SMS messages must contain a link to a page where users can view their waitlist status.\n- Waitlist-only merchants do not need to provide availability feeds to the Actions Center.\n- Your booking server must implement all the waitlist-specific steps listed in [Implement the booking server](/actions-center/verticals/reservations/waitlists/integration-steps/implement-waitlist-booking-server). Partners that support both reservations and waitlists can add on the new methods to their existing booking server.\n- The Actions Center runs a set of [test cases](/actions-center/verticals/reservations/waitlists/integration-steps/overview#test-cases) for the waitlist methods in the booking server.\n\n### Status flowchart\n\n\nThis chart describes the statuses that must be reported in\n[`WaitlistEntry.waitlist_entry_state`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitlistentry-definition) when responding to\n[`GetWaitlistEntry`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/getwaitlistentry-method) calls. The chart also indicates when to record and populate the\n[`WaitlistEntry.waitlist_entry_state_times.*_time_seconds`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitlistentry-definition) fields and when to send an SMS to the user to inform them they have entered a new state.\n**Figure: 3** Waitlist status flowchart\n\n### Common edge cases\n\nThe following are common edge cases in a Reservations Waitlists integration and preferred\nsolutions for them.\n\n- If some (but not all) party sizes are not accepting new waitlist additions because there is no wait on these party sizes then returning `WaitEstimates` for all party sizes in the `BatchGetWaitEstimates` response and allowing users to join the waitlist for these party sizes with no wait is preferred. Return a `WaitLength` with 0 `parties_ahead_count` and/or with an `estimated_seat_time_range` with 0 `start_seconds` and with 0 `end_seconds` for the `party_size`s with no wait\n- If one or more party sizes are not accepting new waitlist additions because the wait has become too long then omitting `WaitEstimates` for those party sizes in the `BatchGetWaitEstimates` response is preferred.\n\nThese approaches are preferred since they give the user options even though\nthe merchant's waitlist may not be fully open.\n\nGuidelines for Reservations Waitlists-only partners\n---------------------------------------------------\n\nKeep the following in mind if the booking server is used only for\nwaitlists:\n\n- Reservations Waitlists-only partners don't provide availability feeds to Reserve with Google.\n- Reservations Waitlists-only partners do not implement the reservation methods in their booking server. Instead, you [Implement the booking server](/actions-center/verticals/reservations/waitlists/integration-steps/implement-waitlist-booking-server) with the instructions for the Waitlist implementation.\n- Reservations Waitlists-only partners do not make API calls to Google. This means that Reservations Waitlists-only partners do not need to set up a cloud project or provide a developer email address. You do not need to complete [Real-time API updates](/actions-center/verticals/reservations/waitlists/integration-steps/real-time-api-updates). However, [merchant](/actions-center/verticals/reservations/waitlists/reference/feeds/merchants-feed) and [service](/actions-center/verticals/reservations/waitlists/reference/feeds/services-feed) feeds still need to be provided to the Actions Center.\n\nGuidelines for partners whose merchants must\nmanually accept/reject waitlist additions\n--------------------------------------------------------------------------------------\n\nIf your merchants require the ability to manually accept or reject new\nwaitlist additions from Google, extra steps are required:\n\n- Set the `waitlist_confirmation_mode` to `WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS` in the `wait_estimate` for party sizes which require manual confirmation. This must be set in the [`BatchGetWaitEstimateResponse`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/batchgetwaitestimates-method) and the [`GetWaitlistEntryResponse`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/getwaitlistentry-method).\n- Waitlist entries that have been requested by the user, but not yet accepted by the merchant should be in state `PENDING_MERCHANT_CONFIRMATION`.\n\nReservations Waitlists test cases\n---------------------------------\n\nGoogle tests the following use cases to ensure the functionality of the\nwaitlist methods in your booking server implementation. Google also tests and\nmonitors latency. All of these tests must pass prior to launch.\n\n### WaitEstimate retrieval\n\n- Wait estimates are returned for each party size requested in a `BatchGetWaitEstimatesRequest`.\n- For party sizes which the merchant has the option to accept or reject new waitlist additions, set waitlist_confirmation_mode to `WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS`.\n\n### Waitlist entry creation\n\n- A waitlist entry can be created from a `CreateWaitlistEntry` request.\n- If waitlist entry creation fails, a business logic error shows up in the response.\n- If a `CreateWaitlistEntry` attempt succeeds, the same response is returned when the same `CreateWaitlistEntry` is received again.\n- If a `CreateWaitlistEntry` attempt fails, the server retries when the same `CreateWaitlistEntry` is received again.\n- Waitlist entries show up in the merchant's interface.\n- Calls to `GetWaitlistEntry` successfully return the created waitlist entry.\n\n### Waitlist entry states and timestamps\n\n- Verify that each waitlist entry state is returned properly in the waitlist entry of `GetWaitlistEntry` responses.\n- Verify that each state timestamp is set in the appropriate timestamp field of the waitlist entry in `GetWaitlistEntry` responses.\n\n### Waitlist entry deletion\n\n- Existing waitlist entries can be deleted. The response to a successful delete must be the empty proto `{}`.\n\n### Opt out\n\n- Verify that opted out merchants are treated as described in [Merchant opt out](/actions-center/verticals/reservations/waitlists/integration-steps/overview#merchant-opt-out).\n\nSample waitlist service feed (JSON)\n-----------------------------------\n\n[Waitlist service feed](/actions-center/verticals/reservations/waitlists/reference/feeds/services-feed)\n\nMerchant opt out\n----------------\n\nGoogle expects certain responses for merchants that previously had waitlists\nenabled but have decided to opt out.\n\n### Immediate opt out\n\n- Return [`CLOSED_OTHER`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitlistbusinesslogicfailure-definition) for [`BatchGetWaitEstimates`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/batchgetwaitestimates-method) requests.\n- Return [`WAITLIST_CLOSED`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitlistbusinesslogicfailure-definition) for [`CreateWaitlistEntry`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/createwaitlistentry-method) requests.\n- Return [`GetWaitlistEntry`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/getwaitlistentry-method) requests properly for users who are already on the waitlist.\n\n### Extended opt out\n\n- Remove the `waitlist_rules` from the service feed for the merchant if the merchant is not opting out of reservations.\n- Remove the merchant from the merchant feed if they opt out of all Google integrations."]]