接続の対応付けを確定する

拠点と掲載情報の対応付け候補を受け入れて確定し、Listings API の拠点と、それに対応する Google Business Profile または Facebook の掲載情報との間に実際の接続を確立します。確定すると、掲載情報は対応する Listings API の拠点との同期を開始します。

リクエストの形式。 リクエストボディは input オブジェクトでラップする必要があり、このオブジェクトが受け付けるフィールドは、対応付けレコードの ID の配列である matchRecordIds（[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()

デコードしてもこれら 3 つの型のいずれにもならない ID では、400 は生成されません。呼び出しは success: false を含み、failedIds を含まない HTTP 200 を返すため、呼び出しのたびに success を確認してください。

このエンドポイントは一括接続ワークフローの最終手順です。アカウントを接続し、POST /connected-accounts/trigger-matches を実行して候補を生成し、接続候補エンドポイントで候補をレビューした後、承認済みのレコードをここで確定します。

ユースケース：レビュー済みの対応付けを一括で受け入れる。 代理店がクライアントの Google アカウントをインポートし、独自に用意した UI で対応付け候補をレビューした後、対応付けごとに 1 回ずつ呼び出すのではなく、承認済みの matchRecordIds を 1 回の呼び出しで送信します。未レビューの候補や誤った候補が変更されないよう、担当者が承認した ID のみを送信してください。

対応付けを確定しても、Google や Facebook にデータが直ちに送信されるわけではありません。Listings API の拠点を掲載先の掲載情報に紐付けることで、その後の掲載情報の更新が反映されるようになります。呼び出しが成功すると、failedIds: null を含む success: true が返されます。1 つ以上の ID を確定できなかった場合（たとえば、対応付けレコードが不明または使用済みの場合や、対応付け対象の拠点がその後アーカイブされた場合）、それらの ID が failedIds に返され、success が false になるため、再試行したり、失敗したものだけを表示したりできます。failedIds に含まれるのは、送信したエンコード済みの値ではなく、デコード済みのデータベース ID なので、matchedDataDatabaseId と照合してください。候補を経由せずに単一の掲載情報を手動で選択する場合は、代わりに connect-listing エンドポイントを使用してください。