商家上線時，Google 會在實際執行環境中啟用所有符合資格的廣告空間。到這裡就代表整合作業已完成，外部使用者將可透過 Actions Center 預訂庫存清單項目。
商家上線後，請務必監控整合作業的狀態。您必須維持下列門檻標準，否則將會導致整合遭移除。
動態饋給
- 動態饋給應每日傳送，且不可出現任何錯誤或警告
- 處理指示應設為 PROCESS_AS_COMPLETE
- 對於供應情形動態饋給，完整商品目錄每日動態饋給上傳作業不應設定任何
_restrict欄位。
預訂伺服器
所有預訂伺服器實作項目都應納入 HealthCheck 路徑。Google 會定期檢查您的 HealthCheck 路徑，如果未收到回應或傳回不正常的回應，我們會暫時停用您的整合。我們會持續定期檢查您的 HealthCheck 路徑，一旦路徑恢復傳回正常回應，我們就會自動還原您的整合。
| 標準導入 | ||
|---|---|---|
| 方法 | 錯誤率門檻 | 延遲時間門檻 |
| CheckAvailability | <10% | 5 秒以下 |
| BatchAvailabilityLookup | 低於 3% | 1.5 秒以下 |
| CreateLease | <10% | 5 秒以下 |
| CreateBooking UpdateBooking |
低於 5% | 4 秒以下 |
| CreateBooking (含付款) |
低於 5% | 15 秒以下 |
| SetMarketingPreference | 不到 5% | 5 秒以下 |
| 等候名單導入 | ||
|---|---|---|
| 方法 | 錯誤率門檻 | 延遲時間門檻 |
| BatchGetWaitEstimates | 低於 3% | 1 秒以下 |
| CreateWaitlistEntry GetWaitlistEntry DeleteWaitlistEntry |
低於 5% | 4 秒以下 |
即時更新
對於即時更新，系統將依據採取行動 (例如修改預訂) 與「透過 Google 預訂」收到即時更新要求，這兩者的時間差來計算延遲時間。
| API | 錯誤率門檻 | 延遲時間門檻 |
|---|---|---|
| AvailabilityReplace RTU | 每天低於 10% | 5 分鐘以下 |
| BookingNotification RTU | 各種情況每天均低於 10% | 5 分鐘以下 |