Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Tout partenaire participant au programme de listes d'attente pour les réservations doit d'abord terminer de configurer son compte. Cependant, certaines étapes du guide général ne sont pas requises dans le cas de l'utilisation de la fonctionnalité de listes d'attente. Vous trouverez sur cette page une explication des étapes qui s'appliquent aux partenaires souhaitant utiliser la fonctionnalité de listes d'attente de Réserver avec Google. Nous vous conseillons de lire cette présentation avant de suivre les étapes d'intégration.
Processus de lancement
La figure 1 présente le processus de lancement de la fonctionnalité Réserver avec Google pour vos marchands qui utilisent la fonctionnalité de listes d'attente dans Actions Center.
Figure 1:Vue d'ensemble des étapes d'intégration
La figure 2 présente les principaux flux de données échangés entre vous (le partenaire) et Google:
Figure 2 : Diagramme présentant les flux de données d'intégration
Consignes pour tous les partenaires de la fonctionnalité Liste d'attente pour les réservations
Tenez compte des points suivants lorsque vous mettez en œuvre la fonctionnalité de listes d'attente pour les réservations:
waitlist_rules doit être renseigné pour le service de chaque marchand avec listes d'attente.
Vous devez utiliser le même service pour la liste d'attente et la réservation. En d'autres termes, si votre restaurant accepte également les réservations, il vous suffit d'ajouter les métadonnées associées à la liste d'attente au service de réservation.
L'envoi de notifications par SMS est obligatoire pour l'implémentation de la liste d'attente dans les cas suivants :
Pour confirmer que l'utilisateur a bien rejoint la liste d'attente.
Pour avertir l'utilisateur que sa table est prête.
Pour informer l'utilisateur que son inscription sur la liste d'attente a été annulée.
Les messages SMS doivent contenir un lien vers une page sur laquelle les utilisateurs peuvent consulter leur état de liste d'attente.
Les marchands qui n'utilisent que des listes d'attente n'ont pas besoin de fournir de flux disponibilité à Actions Center.
Votre serveur de réservation doit intégrer toutes les étapes spécifiques aux listes d'attente décrites dans la section Mettre en œuvre le serveur de réservation. Les partenaires dont les systèmes sont compatibles à la fois avec les réservations et avec les listes d'attente peuvent ajouter les nouvelles méthodes à leur serveur de réservation existant.
Le centre d'actions exécute un ensemble de scénarios de test pour les méthodes liées aux listes d'attente intégrées au serveur de réservation.
Figure 3: Organigramme de l'état de la liste d'attente
Problèmes courants
Vous trouverez ci-dessous une liste de différents problèmes pouvant survenir au niveau de l'intégration de listes d'attente de réservations et les solutions que nous vous recommandons.
Il peut arriver qu'il n'y ait aucun temps d'attente pour les groupes d'un certain nombre de personnes, mais qu'il y en ait pour les autres groupes, autrement dit que dans certains cas, l'ajout dans une liste d'attente n'a pas lieu. Nous vous recommandons alors de renvoyer la valeur WaitEstimates pour tous les cas dans la réponse BatchGetWaitEstimates et de permettre aux utilisateurs pour lesquels il n'y a aucun temps d'attente d'être ajoutés à la liste. Renvoyez un WaitLength avec 0 parties_ahead_count et/ou un estimated_seat_time_range avec 0 start_seconds et 0 end_seconds pour les party_size sans attente.
Il peut également arriver que dans certains cas, l'ajout dans une liste d'attente n'est plus nécessaire, car le temps d'attente est désormais trop long. Nous vous recommandons alors d'omettre la valeur WaitEstimates dans la réponse BatchGetWaitEstimates dans de tels cas.
Nous vous recommandons ces solutions, car elles donnent à l'utilisateur différentes options, même si la liste d'attente du marchand n'est pas complètement activée.
Consignes pour les partenaires n'utilisant que des listes d'attente pour les réservations
Tenez compte des points suivants si le serveur de réservation est utilisé seulement pour des listes d'attente:
Les partenaires qui n'utilisent le serveur que pour des listes d'attente ne fournissent pas de flux disponibilité à Réserver avec Google.
Réservations Les partenaires qui n'utilisent le serveur que pour des listes d'attente ne mettent pas en œuvre les méthodes liées aux réservations. Ils doivent plutôt mettre en œuvre le serveur de réservation en suivant les instructions concernant la mise en œuvre basée sur des listes d'attente.
Les partenaires qui n'utilisent le serveur que pour des listes d'attente n'envoient pas d'appels d'API à Google. Cela signifie qu'ils n'ont pas besoin de configurer un projet sur le cloud ni de fournir l'adresse e-mail d'un développeur. Vous n'avez pas besoin d'effectuer de mises à jour de l'API en temps réel. Toutefois, vous devez toujours fournir des flux marchands et services à Actions Center.
Consignes pour les partenaires dont les marchands doivent accepter/refuser manuellement les ajouts aux listes d'attente
Des étapes supplémentaires sont nécessaires si vos marchands exigent d'avoir la possibilité d'accepter ou de refuser manuellement de nouvelles entrées dans des listes d'attente provenant de Google:
Dans le champ wait_estimate, définissez le mode waitlist_confirmation_mode sur WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS lorsqu'une confirmation manuelle est requise en fonction du nombre de personnes. Cette valeur doit être définie à la fois dans BatchGetWaitEstimateResponse et dans GetWaitlistEntryResponse.
Définissez l'état PENDING_MERCHANT_CONFIRMATION pour les entrées dans une liste d'attente demandées par l'utilisateur, mais pas encore acceptées par le marchand.
Scénarios de test pour les listes d'attente pour les réservations
Google teste les cas d'utilisation suivants pour s'assurer du bon fonctionnement des méthodes de listes d'attente dans la mise en œuvre de votre serveur de réservation. Google teste et surveille également la latence. Tous ces tests doivent réussir avant le lancement.
Récupération de la valeur WaitEstimate
Des estimations d'attente sont renvoyées pour tout nombre de personnes demandé dans une requête BatchGetWaitEstimatesRequest.
Pour tout nombre de personnes pour lequel le marchand a la possibilité d'accepter ou de refuser de nouvelles entrées dans la liste d'attente, définissez le paramètre waitlist_confirmation_mode sur WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS.
Créer une entrée dans une liste d'attente
Une entrée dans une liste d'attente peut être créée à partir d'une requête CreateWaitlistEntry.
Si la création d'une entrée dans une liste d'attente échoue, une erreur de logique métier s'affiche dans la réponse.
Si une tentative de requête CreateWaitlistEntry réussit, la même réponse est renvoyée lorsque la même requête CreateWaitlistEntry est reçue de nouveau.
Si une tentative de requête CreateWaitlistEntry échoue, le serveur effectue une nouvelle tentative lorsque la même requête CreateWaitlistEntry est reçue de nouveau.
Les entrées dans des listes d'attente s'affichent dans l'interface du marchand.
Les appels à GetWaitlistEntry renvoient l'entrée dans une liste d'attente qui a été créée.
États et horodatages des entrées dans des listes d'attente
Vérifiez que chaque état d'entrée dans la liste d'attente est correctement renvoyé dans l'entrée correspondante des réponses GetWaitlistEntry.
Vérifiez que chaque horodatage d'état est défini dans le champ d'horodatage approprié de l'entrée dans la liste d'attente des réponses GetWaitlistEntry.
Supprimer une entrée dans une liste d'attente
Les entrées existantes dans des listes d'attente peuvent être supprimées. La réponse à une suppression réussie doit être le proto {} vide.
Google s'attend à certaines réponses de la part de marchands qui utilisaient précédemment la fonctionnalité des listes d'attente, mais qui ont décidé de la désactiver.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/26 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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."]]
