確認連線配對

接受並確認建議的地點與商家資訊配對，在 Listings API 地點及其對應的 Google Business Profile 或 Facebook 商家資訊之間建立正式連線。確認後，商家資訊便會開始與配對的 Listings API 地點同步。

請求格式。 請求主體必須包裝在 input 物件中，且該物件只接受 matchRecordIds 欄位，其值為配對記錄 ID 的陣列（[ID!]!，必填）。傳送未包裝的扁平主體會遭到拒絕，並傳回 HTTP 400；在 input 內部傳送未知欄位，例如 connectedAccountId 或舊版的 matchIds（Unknown field "connectedAccountId"），也會如此。位於 input 外部的多餘鍵會被忽略，而不會導致請求遭到拒絕。此請求沒有 connectedAccountId 欄位；帳戶會從配對記錄本身推斷。

建立 matchRecordIds 值。 連線建議記錄沒有 id。取出其 matchedDataDatabaseId 和 accountType，以冒號串接並置於配對記錄類型名稱之後，再以 base64 編碼結果：

import base64 TYPES = {    "GMB": "GmbLocationMatchedData",    "FB": "FbLocationMatchedData",    "APPLE": "AppleLocationMatchedData",} def match_record_id(record):    raw = f"{TYPES[record['accountType']]}:{record['matchedDataDatabaseId']}"    return base64.b64encode(raw.encode()).decode()

若 ID 無法解碼為這 3 種類型之一，就不會產生 400。呼叫會傳回 HTTP 200 和 success: false，但不含 failedIds，因此請在每次呼叫時檢查 success。

此端點是批次連結工作流程的最後一步：連結帳戶、執行 POST /connected-accounts/trigger-matches 以產生建議、透過連線建議端點檢視建議，然後在此確認已核准的記錄。

使用案例：批次接受已檢視的配對。 代理商匯入客戶的 Google 帳戶，並在您自己的 UI 中檢視建議配對後，透過一次呼叫提交已核准的 matchRecordIds，無須為每個配對各呼叫一次。請只傳送操作人員已核准的 ID，讓未經檢視或錯誤的建議維持不變。

確認配對不會立即將資料推送至 Google 或 Facebook；此操作會將 Listings API 地點連結至發布平台的商家資訊，讓後續的商家資訊更新能透過此連線傳送。呼叫成功時會傳回 success: true 和 failedIds: null。當 1 個或多個 ID 無法確認時（例如，配對記錄不存在或已使用，或配對的地點在此期間已封存），這些 ID 會透過 failedIds 傳回，且 success 為 false，讓您可以重試或只顯示失敗項目。failedIds 包含的是解碼後的資料庫 ID，而非您傳送的編碼值，因此請將它們與 matchedDataDatabaseId 比對。若要略過建議流程，手動選取單一商家資訊，請改用 connect-listing 端點。