Our team schedules the launch for a specific date and time. You may see a delay of merchants going online over several hours.
Your integration is monitored for a week after the launch. If your Booking Server or Real-Time Updates (RTUs) are over any error thresholds, we will inform you to correct them. If the issues aren't resolved, Google will take down your integration.
Booking Server
For all Booking Server implementations, there is a HealthCheck route that must
be included. The Actions Center periodically checks your HealthCheck route.
If it doesn't respond or returns an unhealthy response, we temporarily disable
your integration. We continue to periodically check your HealthCheck route
and after it returns a healthy response, we automatically restore your
integration.
| Standard implementation methods | Error rate thresholds | Latency thresholds |
|---|---|---|
CheckAvailability
Note: This booking server endpoint is legacy. New integrations must not
implement this endpoint.
|
<10% | <5s |
BatchAvailabilityLookup
|
<3% | <1.5s |
CreateBooking
|
<5% | <4s |
RTUs
For RTUs, latency is measured by the time difference between when an action is taken (for example, modifying a booking) and when Actions Center receives the RTU request.
| API | Error rate thresholds | Latency thresholds |
|---|---|---|
BookingNotification RTU
|
<10% each day and for each state | <5 minutes |
You can monitor error rates through the various Partner Portal dashboards, namely the Feeds, Booking Server, and RTU dashboards.
Inventory Compliance requirements
Make sure that you continue to follow the Inventory Compliance requirements.
For information on how a merchant can opt out of your service, see
the Remove third-party links section of
the help article.
If you violate the Inventory Compliance policy, your integration could be
disabled or terminated.