Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Los socios que participan en el programa de listas de espera de reservas deben completar la configuración de la cuenta antes de comenzar. Sin embargo, algunos pasos de la guía general no son necesarios para usar la función de listas de espera. Los lineamientos de esta página explican qué pasos deben seguir los socios que deseen usar la función de listas de espera en Reserva con Google. Te sugerimos que leas esta descripción general antes de seguir los pasos de la integración.
Proceso de lanzamiento
En la figura 1, se describe el proceso que se debe realizar para lanzar los comercios habilitados para utilizar listas de espera en Actions Center.
Figura 1: Pasos de integración de alto nivel
En general, los principales flujos de datos entre Google y tú (el socio) se muestran en la Figura 2:
Figura 2: Diagrama de flujo de datos de la integración
Lineamientos para todos los socios de las listas de espera de reservas
Ten en cuenta lo siguiente cuando implementes la función de listas de espera de reservas:
El servicio de todos los comercios que usan listas de espera de reservas debe tener waitlist_rules propagado.
Debes usar el mismo servicio para la lista de espera y la reserva. En otras palabras, si tu
restaurante también permite reservas, solo agrega los metadatos relacionados con la lista de espera al servicio
de reserva.
El envío de actualizaciones por SMS es obligatorio para la implementación de la lista de espera en los siguientes casos:
Para confirmar que el usuario se unió correctamente a la lista de espera.
Notificar al usuario que su mesa está lista
Para notificarle al usuario que se canceló su entrada en la lista de espera.
Los mensajes SMS deben contener un vínculo a una página en la que los usuarios puedan ver su estado en la lista de espera.
Los comercios que solo usan listas de espera no necesitan proporcionar feeds de disponibilidad a Acciones Center.
Tu servidor de reservas debe implementar todos los pasos específicos para las listas de espera que se detallan en Implementa el servidor de reservas. Los socios que admiten reservas y listas de espera pueden agregar los nuevos métodos a su servidor de reservas existente.
El Centro de Acciones ejecuta un conjunto de casos de prueba para los métodos de lista de espera en el servidor de reservas.
Figura 3: Flujo de trabajo del estado de la lista de espera
Casos extremos comunes
A continuación, se describen algunos casos extremos comunes que pueden ocurrir en una integración de listas de espera de reservas y las soluciones recomendadas para ellos.
Si algunos tamaños de grupo (pero no todos) no aceptan nuevas incorporaciones a la lista de espera porque no hay tiempo de espera para estos tamaños, es preferible mostrar WaitEstimates para todos los tamaños de grupo en la respuesta BatchGetWaitEstimates y permitir a los usuarios unirse a la lista de espera para estos tamaños sin tiempo de espera. Muestra un WaitLength con 0 parties_ahead_count o con un estimated_seat_time_range con 0 start_seconds y 0 end_seconds para los party_size sin espera.
Si uno o más tamaños de grupo no aceptan nuevas incorporaciones a la lista de espera porque la espera es demasiado extensa, es preferible omitir WaitEstimates para esos tamaños en la respuesta BatchGetWaitEstimates.
Se prefiere utilizar estos enfoques, ya que brindan opciones al usuario aunque la lista de espera del comercio no esté completamente abierta.
Lineamientos para socios que solo usan listas de espera de reservas
Ten en cuenta lo siguiente si el servidor de reservas se usa solo para las listas de espera:
Los socios que solo usan listas de espera para reservas no proporcionan feeds de disponibilidad a Reserva con Google.
Los socios que solo usan listas de espera no implementan los métodos de reserva en su servidor de reservas. En cambio, debes implementar el servidor de reservas con las instrucciones para la implementación de listas de espera.
Los socios que solo usan listas de espera de reservas no realizan llamadas a la API a Google. Esto significa que los socios que solo usan listas de espera de reservas no necesitan configurar un proyecto en la nube ni proporcionar una dirección de correo electrónico de desarrollador. No es necesario que completes las actualizaciones de la API en tiempo real. Sin embargo, sí debes proporcionar los feeds de comercio y servicio a Actions Center.
Lineamientos para socios cuyos comercios deben aceptar o rechazar manualmente las incorporaciones a listas de espera
Si tus comercios necesitan aceptar o rechazar manualmente las nuevas incorporaciones a listas de espera de Google, deben seguir pasos adicionales:
Establece waitlist_confirmation_mode como WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS en wait_estimate para los tamaños de grupo que requieren confirmación manual. Esto se debe configurar en BatchGetWaitEstimateResponse y GetWaitlistEntryResponse.
Las entradas de lista de espera que haya solicitado el usuario, pero que el comercio todavía no haya aceptado deben tener el estado PENDING_MERCHANT_CONFIRMATION.
Casos de prueba de las listas de espera de reservas
Google prueba los siguientes casos de uso para garantizar la funcionalidad de los métodos de las listas de espera en la implementación del servidor de reservas. Google también prueba y
supervisa la latencia. Todas estas pruebas deben aprobarse antes del lanzamiento.
Recuperación de WaitEstimate
Las estimaciones del tiempo de espera se muestran para cada tamaño de grupo solicitado en un BatchGetWaitEstimatesRequest.
En el caso de los tamaños de grupo para los que el comercio tiene la opción de aceptar o rechazar nuevas incorporaciones a la lista de espera, configura waitlist_confirmation_mode como WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS.
Creación de entradas de lista de espera
Se puede crear una entrada de lista de espera a partir de una solicitud CreateWaitlistEntry.
Si la creación de la entrada de lista de espera falla, aparecerá un error de lógica empresarial en la respuesta.
Si un intento de CreateWaitlistEntry se ejecuta correctamente, se muestra la misma respuesta cuando se vuelve a recibir el mismo CreateWaitlistEntry.
Si un intento de CreateWaitlistEntry falla, el servidor volverá a intentarlo cuando se reciba el mismo CreateWaitlistEntry.
Las entradas de lista de espera aparecen en la interfaz del comercio.
Las llamadas a GetWaitlistEntry muestran correctamente la entrada de lista de espera creada.
Estados y marcas de tiempo de las entradas de lista de espera
Verifica que cada estado de la entrada de lista de espera se muestre correctamente en la entrada de lista de espera de las respuestas GetWaitlistEntry.
Verifica que cada marca de tiempo de estado esté configurada en el campo de marca de tiempo correspondiente de la entrada de lista de espera en las respuestas de GetWaitlistEntry.
Eliminación de entradas de lista de espera
Es posible borrar entradas de lista de espera existentes. La respuesta a una eliminación exitosa debe ser el protocolo vacío {}.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]