사용자가 대기자 명단 항목을 만들면 Google에서 사용자의 이름, 성, 전화번호, 이메일을 전송합니다. 이메일은 사용자의 Google 계정과 동일하며 고유 식별자로 처리됩니다. 이 대기자 명단은
Google 예약이 시스템에서 사용자 계정을 조회할 수 없기 때문에
비회원 결제로 처리되어야 합니다. 최종 대기자 명단 항목이 대기자 명단 시스템에서 오는 판매자의 항목과 동일하게 표시되는지 확인합니다.
보안 및 인증
예약 서버와의 모든 통신은 HTTPS를 통해 이루어지므로 서버에 DNS 이름과 일치하는 유효한 TLS 인증서가 있어야 합니다. 서버를 설정하는 데 도움이 되도록 Qualys SSL 서버 테스트와 같이 무료로 제공되는 SSL/TLS 확인 도구를 사용하는 것이 좋습니다.
Google에서 예약 서버에 보내는 모든 요청은 HTTP 기본 인증을 사용하여 인증됩니다. 예약 서버의 기본 사용자 인증 정보(사용자 이름 및 비밀번호)는 파트너 포털의 예약 서버 구성 페이지에 입력할 수 있습니다. 비밀번호는 6개월마다 변경되어야 합니다.
샘플 스켈레톤 구현
시작하려면 Node.js 및 Java 프레임워크용으로 작성된 예약 서버의 다음 샘플 스켈레톤을 확인하세요.
이러한 오류를 표준 HTTP 오류 코드와 함께 클라이언트에 반환합니다.
전체 HTTP 상태 코드 목록을 참고하세요.
비즈니스 로직과 관련된 오류
HTTP 상태 코드를 200 OK로 설정하고 응답 본문에 비즈니스 로직 실패를 지정합니다. 발생할 수 있는 비즈니스 로직 오류 유형은 서버 구현 유형에 따라 다릅니다.
예약 대기자 명단 통합의 경우 비즈니스 로직 오류는 대기자 명단 비즈니스 로직 실패에 캡처되며 HTTP 응답으로 반환됩니다. 리소스를 만들 때(예: CreateWaitlistEntry 메서드 처리 시) 비즈니스 로직 오류가 발생할 수 있습니다. 이러한 예에는 다음 항목이 포함되나 이에 국한되지 않습니다.
ABOVE_MAX_PARTY_SIZE는 요청된 대기자 명단 항목이 판매자의 최대 인원수를 초과할 때 사용됩니다.
MERCHANT_CLOSED는 판매자가 이미 폐쇄되어 대기자 명단을 열지 않은 경우에 사용됩니다.
멱등성
네트워크를 통한 통신이 항상 신뢰할 수 있는 것은 아니며 응답을 받지 못하면 Google에서 HTTP 요청을 다시 시도할 수 있습니다. 따라서 상태를 변경하는 모든 메서드는 멱등성을 갖춰야 합니다.
CreateWaitlistEntry
DeleteWaitlistEntry
DeleteWaitlistEntry를 제외한 모든 요청 메시지에 멱등성 토큰이 포함되어 요청을 고유하게 식별합니다. 이렇게 하면 단일 요청을 만드는 인텐트와 두 개의 개별 요청을 사용하여 재시도된 REST 호출을 구분할 수 있습니다.
DeleteWaitlistEntry는 각각 대기자 명단 항목 ID로 고유하게 식별되므로 요청에 멱등성 토큰이 포함되지 않습니다.
다음은 예약 서버가 멱등성을 처리하는 방법의 몇 가지 예입니다.
성공적인 CreateWaitlistEntry HTTP 응답에는 생성된 대기자 명단 항목 ID가 포함됩니다. 동일한 CreateWaitlistEntryRequest가 두 번째로 수신되면 (동일한 idempotency_token 포함) 동일한 CreateWaitlistEntryResponse가 반환되어야 합니다. 두 번째 대기자 명단 항목이 생성되지 않으며 오류가 반환되지 않습니다.
CreateWaitlistEntry 시도가 실패하고 동일한 요청이 다시 전송되면 백엔드에서 이를 다시 시도해야 합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-26(UTC)"],[[["\u003cp\u003eYou need a booking server to enable the Actions Center to create and update bookings for users.\u003c/p\u003e\n"],["\u003cp\u003eTwo implementations exist: Reservations Waitlists for managing waitlists and the Standard implementation for appointments and bookings.\u003c/p\u003e\n"],["\u003cp\u003eYour booking server must implement a REST API interface for Google to send requests.\u003c/p\u003e\n"],["\u003cp\u003eImplement security measures like HTTPS and HTTP basic authentication to ensure secure communication.\u003c/p\u003e\n"],["\u003cp\u003eHandle HTTP and business logic errors gracefully and ensure all state-mutating methods are idempotent for reliable communication.\u003c/p\u003e\n"]]],["To enable Actions Center bookings, implement a booking server with a REST API interface over HTTPS. The server can handle standard bookings or waitlist entries. It must support specific API methods (e.g., `HealthCheck`, `CreateWaitlistEntry`), handle HTTP and business logic errors, and ensure requests that alter state are idempotent. Use unique tokens for retryable actions. Configure server credentials and choose between sandbox or production environments. Utilize provided code samples for implementation and validate TLS certificate.\n"],null,["# Step 3: Implement the Waitlists booking server\n\nYou need to stand up a booking server to allow the Actions Center to make callbacks to create and\nupdate bookings on your behalf.\n\n- **The Reservations Waitlists implementation.** This is used when you participate in the Reservations Waitlists pilot program. This allows the Actions Center to retrieve wait estimates and create waitlist entries on behalf of the user.\n- **The Standard implementation.** This allows the Actions Center to create appointments, bookings, and reservations with you on behalf of the user. To implement a booking server for the Reservations End-to-End integration please refer to [Implement the booking server](/actions-center/verticals/reservations/waitlists/integration-steps/implement-booking-server).\n\nRefer to the\n[Partner Portal](/actions-center/verticals/reservations/waitlists/partner-portal/testing/booking-server-endpoint-and-credentials) documentation to learn how to configure the connection\nto your sandbox and production booking servers.\n\nImplement a REST API interface\n------------------------------\n\nImplement an API interface based on\n[REST](http://en.wikipedia.org/wiki/Representational_State_Transfer) This allows Google to send booking server\nrequests over HTTP.\n\nTo start, set up a development or sandbox booking server that can be\nconnected to the Actions Center sandbox environment. Only move to a\nproduction environment once the sandbox server is fully tested.\n\n### Methods\n\nFor each type of booking server, a different set of API methods are required\non your end. Optionally, you can download the service definition in proto\nformat to get started with the API implementation. The following tables show\nthe methods for each implementation and include links to the service proto\nformats.\n\n| Waitlist implementation |\n|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| [Waitlist service definition](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/proto-interface). Download the proto service definition file. |\n\n| Method | HTTP Request |\n|------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------|\n| [HealthCheck](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/healthcheck-method) | GET /v3/HealthCheck/ |\n| [BatchGetWaitEstimates](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/batchgetwaitestimates-method) | POST /v3/BatchGetWaitEstimates/ |\n| [CreateWaitlistEntry](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/createwaitlistentry-method) | POST /v3/CreateWaitlistEntry/ |\n| [GetWaitlistEntry](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/getwaitlistentry-method) | POST /v3/GetWaitlistEntry/ |\n| [DeleteWaitlistEntry](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/deletewaitlistentry-method) | POST /v3/DeleteWaitlistEntry/ |\n\n### API resources\n\n#### Waitlist\n\nThe following resources are used to implement waitlist-based booking:\n\n- [WaitEstimate](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitestimate-definition): A wait estimate for a specific party size and merchant.\n- [WaitlistEntry](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitlistentry-definition): A user's entry in the waitlist.\n\n### Flow: create a waitlist entry\n\nThis section covers how to create a booking for the Reservations Waitlists integration.\nFigure 2: Workflow to create a waitlist entry\n\nWhen the user creates a waitlist entry, Google sends you the user's given\nname, surname, phone number, and email. The email is the same as the user's\nGoogle account and is treated as a unique identifier. From your point of\nview, this waitlist needs to be treated as a guest checkout, because Reserve\nwith Google can't look up the user's account in your system. Make sure the\nfinal waitlist entry appears identical to your merchants' entries that come\nfrom your waitlist system.\n\n### Security and Authentication\n\nAll communication to your booking server happens over HTTPS, so it's\nessential that your server has a valid TLS certificate that matches its\nDNS name. To help set up your server, we recommend the use of a freely\navailable SSL/TLS verification tool, such as\n[Qualys' SSL Server Test](https://www.ssllabs.com/ssltest/).\n\nAll requests Google will make to your booking server will be authenticated\nusing HTTP basic authentication. The basic authentication credentials\n(username and password) for your booking server can be entered in the\nBooking Server Configuration page within the\n[Partner Portal](https://partnerdash.google.com/apps/reservewithgoogle/configuration/booking-server). Passwords must be rotated every six months.\n| **Note:** You must set username and password for Sandbox and Production separately by using the [Environment switcher](/actions-center/verticals/reservations/waitlists/partner-portal/overview/environment-switcher).\n\n### Sample Skeleton Implementations\n\nTo get started, check out the following sample skeletons of a booking server\nwritten for Node.js and Java frameworks:\n\n- Node.js skeleton [js-maps-booking-rest-server-v3-skeleton](/actions-center/verticals/reservations/waitlists/reference/booking-server-code-samples/node-js)\n- Java skeleton [java-maps-booking-rest-server-v3-skeleton](/actions-center/verticals/reservations/waitlists/reference/booking-server-code-samples//java)\n\nThese servers have stubbed out REST methods.\n| **Note:** For Reservations Waitlists integration, change the REST methods to the required Reservations Waitlists methods.\n\nRequirements\n------------\n\n### HTTP errors and business logic errors\n\nWhen your backend handles HTTP requests, two types of errors may occur.\n\n- **Errors related to infrastructure or incorrect data**\n - Return these errors to the client with standard HTTP error codes. See the [full HTTP status code list](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/status-codes).\n- **Errors related to business logic**\n - Return HTTP status code set to `200` OK, and specify the business logic failure in the response body. The types of business logic errors you can encounter are different for the different types of server implementations.\n\nFor the Reservations Waitlists integraton, business logic errors are captured in\n[Waitlist Business Logic Failure](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-definitions/waitlistbusinesslogicfailure-definition) and they're returned in HTTP\nresponse. Business logic errors may be encountered when a resource is\ncreated, for instance when you handle the `CreateWaitlistEntry`\nmethod. Examples include, but are not limited to, the following:\n\n- `ABOVE_MAX_PARTY_SIZE` is used when the requested waitlist entry is over the merchant's maximum party size.\n- `MERCHANT_CLOSED` is used when the waitlist isn't open because the merchant is already closed.\n\n### Idempotency\n\nCommunication over the network is not always reliable and Google may retry\nHTTP requests if no response is received. For this reason, all methods that\nmutate state must be idempotent:\n\n- `CreateWaitlistEntry`\n- `DeleteWaitlistEntry`\n\nFor every request message except `DeleteWaitlistEntry`, idempotency tokens are included to uniquely\nidentify the request. This allows you to distinguish between a retried REST\ncall, with the intent to create a single request, and two separate requests.\n`DeleteWaitlistEntry` is uniquely\nidentified by their waitlist entry IDs respectively, so no\nidempotency token is included in their requests.\n\n\nThe following are some examples of how booking servers handle idempotency:\n\n- A successful\n [CreateWaitlistEntry](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/createwaitlistentry-method) HTTP response includes the created\n waitlist entry ID. If the same `CreateWaitlistEntryRequest` is\n received a second time (with the same `idempotency_token`),\n then the same `CreateWaitlistEntryResponse` must be returned. No\n second waitlist entry is created and no error is returned.\n\n Note that if a `CreateWaitlistEntry` attempt fails and the\n same request is resent, your backend should retry in this case.\n\nThe idempotency requirement applies to all methods that mutate state."]]
