ユーザーが予約を作成すると、そのユーザーの氏名、電話番号、メールアドレスが販売者に送信されます。Actions Center では、販売者のシステム内のユーザー アカウントを検索できないため、この予約は「ログインせずに決済」として処理する必要があります。最終的な予約内容が、販売者の予約システムの予約内容と同じであることを確認します。
セキュリティと認証
販売者への予約サーバーへの通信はすべて HTTPS 経由で行われるため、サーバーの DNS 名と一致する有効な TLS 証明書が必要です。サーバーの設定では、Qualys の SSL Server Test などの一般公開されている SSL/TLS 検証ツールを使用することをおすすめします。
Google が販売者の予約サーバーに対して行うすべてのリクエストは、HTTP 基本認証を使用して認証されます。販売者の予約サーバーの基本認証の認証情報（ユーザー名とパスワード）は、パートナー ポータルの [予約サーバーの設定] ページで入力できます。パスワードは 6 か月ごとに変更する必要があります。
[null,null,["最終更新日 2025-07-26 UTC。"],[[["\u003cp\u003eSet up a booking server to enable the Actions Center to create and update bookings on your behalf.\u003c/p\u003e\n"],["\u003cp\u003eImplement a REST API interface for Google to send booking server requests over HTTP.\u003c/p\u003e\n"],["\u003cp\u003eFamiliarize yourself with the required API methods for the standard implementation, including \u003ccode\u003eHealthCheck\u003c/code\u003e, \u003ccode\u003eBatchAvailabilityLookup\u003c/code\u003e, \u003ccode\u003eCreateBooking\u003c/code\u003e, \u003ccode\u003eUpdateBooking\u003c/code\u003e, \u003ccode\u003eGetBookingStatus\u003c/code\u003e, and \u003ccode\u003eListBookings\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eEnsure all communication is secure using HTTPS with a valid TLS certificate and HTTP basic authentication for requests.\u003c/p\u003e\n"],["\u003cp\u003eImplement idempotency for \u003ccode\u003eCreateBooking\u003c/code\u003e and \u003ccode\u003eUpdateBooking\u003c/code\u003e methods to handle potential request retries and ensure data consistency.\u003c/p\u003e\n"]]],["The core requirement is to establish a booking server that enables the Actions Center to manage bookings. This involves implementing a REST API with specific methods like `HealthCheck`, `BatchAvailabilityLookup`, `CreateBooking`, `UpdateBooking`, `GetBookingStatus`, and `ListBookings`. The server must support the standard implementation, handle booking and slot resource types, and process user data as guest checkouts. All communications should be over HTTPS with HTTP basic authentication, and `CreateBooking` and `UpdateBooking` must be idempotent. You should set up a sandbox environment for testing before going live.\n"],null,["# Step 4: Implement the 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 Standard implementation.** This allows the Actions Center to create appointments, bookings, and reservations with you on behalf of the user.\n\nRefer to the\n[Partner Portal](/actions-center/verticals/local-services/e2e/partner-portal/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| Standard implementation |\n|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| [Standard service definition](/actions-center/verticals/local-services/e2e/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/local-services/e2e/reference/booking-server-api-rest/e2e-methods/healthcheck-method) | GET /v3/HealthCheck/ |\n| [BatchAvailabilityLookup](/actions-center/verticals/local-services/e2e/reference/booking-server-api-rest/e2e-methods/batchavailabilitylookup-method) | POST /v3/BatchAvailabilityLookup/ |\n| [CreateBooking](/actions-center/verticals/local-services/e2e/reference/booking-server-api-rest/e2e-methods/createbooking-method) | POST /v3/CreateBooking/ |\n| [UpdateBooking](/actions-center/verticals/local-services/e2e/reference/booking-server-api-rest/e2e-methods/updatebooking-method) | POST /v3/UpdateBooking/ |\n| [GetBookingStatus](/actions-center/legacy/reference/booking-server/getbookingstatus-method) | POST /v3/GetBookingStatus/ |\n| [ListBookings](/actions-center/legacy/reference/booking-server/listbookings-method) | POST /v3/ListBookings/ |\n\n### API resources\n\n#### Booking\n\nThe following resource types are used in the standard implementation:\n\n- [Slot](/actions-center/verticals/local-services/e2e/reference/booking-server-api-rest/e2e-definitions/slot-definition): An inventory slot.\n- [Booking](/actions-center/verticals/local-services/e2e/reference/booking-server-api-rest/e2e-definitions/booking-definition): An appointment for an inventory slot.\n\n### Flow: create a booking\n\nThis section covers how to create a booking for the standard implementation.\nFigure 1: Workflow to create a booking from a slot\n\n\nWhen a user creates a booking, Google sends you the user's given name,\nsurname, phone number, and email. From your point of view, this booking needs\nto be treated as a guest checkout, because the Actions Center can't look up\nthe user's account in your system. Make sure the final booking appears\nidentical to your merchants' bookings that come from your booking 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 publicly\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/local-services/e2e/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/local-services/e2e/reference/booking-server-code-samples/node-js)\n- Java skeleton [java-maps-booking-rest-server-v3-skeleton](/actions-center/verticals/local-services/e2e/reference/booking-server-code-samples/java)\n\nThese servers have stubbed out REST 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/local-services/e2e/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 Standard implementation, the possible business logic errors are\ncaptured in\n[Booking Failure](/actions-center/verticals/local-services/e2e/reference/booking-server-api-rest/e2e-definitions/bookingfailure-definition) and they're returned in the HTTP response. Business\nlogic errors may be encountered when a resource is created or updated. For\ninstance, when you handle the methods `CreateBooking` or\n`UpdatingBooking`. Examples include, but aren't limited to, the\nfollowing:\n\n- `SLOT_UNAVAILABLE` is used if the requested slot is no longer available.\n- `PAYMENT_ERROR_CARD_TYPE_REJECTED` is used if the provided credit card type is not accepted.\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- `CreateBooking`\n- `UpdateBooking`\n\nFor every request message except `UpdateBooking`, 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`UpdateBooking` is uniquely\nidentified by their booking 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 `[CreateBooking](/actions-center/verticals/local-services/e2e/reference/booking-server-api-rest/e2e-methods/createbooking-method) HTTP response includes the created booking. In\n some cases, payment is processed as part of the booking flow. If the exact\n same `CreateBookingRequest` is received a second time (with the\n same `idempotency_token`), then the same\n `CreateBookingResponse` must be returned. No second booking is\n created, and the user is charged exactly once, if applicable.\n\n Note that if a `CreateBooking` attempt fails and the same\n request is resent, your backend should retry it in this case.\n\nThe idempotency requirement applies to all methods that mutate state."]]
