Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Nasz zespół zaplanuje uruchomienie na konkretną datę i godzinę. Możesz zauważyć opóźnienie w przejściu sprzedawców do trybu online, które może trwać kilka godzin.
Po uruchomieniu integracja jest monitorowana przez tydzień. Jeśli Twój serwer rezerwacji lub aktualizacje w czasie rzeczywistym przekroczą progi błędów, poinformujemy Cię o tym, abyś mógł je poprawić. Jeśli problemy nie zostaną rozwiązane, Google usunie Twoją integrację.
Serwer rezerwacji
W przypadku wszystkich implementacji serwera rezerwacji musi być uwzględniona ścieżka HealthCheck. Centrum działań okresowo sprawdza HealthCheck trasę.
Jeśli nie odpowie lub zwróci nieprawidłową odpowiedź, tymczasowo wyłączymy Twoją integrację. Okresowo sprawdzamy HealthChecktrasę
i gdy otrzymamy prawidłową odpowiedź, automatycznie przywracamy Twoją
integrację.
Standardowe metody implementacji
Progi odsetka błędów
Progi czasu oczekiwania
CheckAvailability
Uwaga: ten punkt końcowy serwera rezerwacji jest starszy. Nowe integracje nie mogą implementować tego punktu końcowego.
<10%
< 5 s
BatchAvailabilityLookup
<3%
<1,5 s
CreateBooking
UpdateBooking
<5%
< 4 s
RTU
W przypadku jednostek RTU opóźnienie jest mierzone jako różnica czasu między wykonaniem działania (np. modyfikacją rezerwacji) a otrzymaniem przez Centrum działań żądania RTU.
API
Progi odsetka błędów
Progi czasu oczekiwania
BookingNotification RTU
mniej niż 10% każdego dnia i w każdym stanie;
< 5 minut
Współczynniki błędów możesz monitorować w różnych panelach Portalu dla partnerów, a mianowicie w panelach Pliki danych, Serwer rezerwacji i RTU.
Wymagania dotyczące zgodności zasobów reklamowych
Pamiętaj, aby nadal przestrzegać wymagań dotyczących zgodności asortymentu.
Informacje o tym, jak sprzedawca może zrezygnować z Twojej usługi, znajdziesz w sekcji Usuwanie linków zewnętrznych w artykule pomocy.
Jeśli naruszysz zasady zgodności z zasobami reklamowymi, Twoja integracja może zostać wyłączona lub zakończona.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 2025-07-26 UTC."],[],[],null,["# Launch and Monitor\n\nOur team schedules the launch for a specific date and time. You may see a delay\nof merchants going online over several hours.\n\nYour integration is monitored for a week after the launch. If your Booking\nServer or Real-Time Updates (RTUs) are over any error thresholds, we will inform\nyou to correct them. If the issues aren't resolved, Google will take down your\nintegration.\n\n### Booking Server\n\nFor all Booking Server implementations, there is a `HealthCheck` route that must\nbe included. The Actions Center periodically checks your `HealthCheck` route.\nIf it doesn't respond or returns an unhealthy response, we temporarily disable\nyour integration. We continue to periodically check your `HealthCheck` route\nand after it returns a healthy response, we automatically restore your\nintegration.\n\n|----------------------------------------------------------------------------------------------------------------------|-------|--------|\n| |||\n| `CheckAvailability` Note: This booking server endpoint is legacy. New integrations must not implement this endpoint. | \\\u003c10% | \\\u003c5s |\n| `BatchAvailabilityLookup` | \\\u003c3% | \\\u003c1.5s |\n| `CreateBooking` `UpdateBooking` | \\\u003c5% | \\\u003c4s |\n\n### RTUs\n\nFor RTUs, latency is measured by the time difference between when an action is\ntaken (for example, modifying a booking) and when Actions Center receives the\nRTU request.\n\n| **API** | **Error rate thresholds** | **Latency thresholds** |\n|---------------------------|-----------------------------------|------------------------|\n| `BookingNotification RTU` | \\\u003c10% each day and for each state | \\\u003c5 minutes |\n\nYou can monitor error rates through the various Partner Portal dashboards,\nnamely the [Feeds](https://partnerdash.google.com/apps/reservewithgoogle/dashboards/feeds),\n[Booking Server](https://partnerdash.google.com/apps/reservewithgoogle/dashboards/bookingserver),\nand [RTU](https://partnerdash.google.com/apps/reservewithgoogle/dashboards/realtimeupdates)\ndashboards.\n\n### Inventory Compliance requirements\n\nMake sure that you continue to follow the [Inventory Compliance requirements](/actions-center/verticals/reservations/e2e/policies/compliance-requirements).\nFor information on how a merchant can opt out of your service, see\nthe **Remove third-party links** section of\nthe [help article](https://support.google.com/business/answer/6218037?hl=en&ref_topic=11498161&sjid=1606319823142007035-NC).\nIf you violate the Inventory Compliance policy, your integration could be\ndisabled or terminated."]]
