연결 매칭 확정

추천된 사업장과 등록 정보의 쌍을 수락하고 확정하여 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와 함께 HTTP 200을 반환하고 failedIds는 반환하지 않으므로, 호출할 때마다 success를 확인합니다.

이 엔드포인트는 일괄 연결 워크플로의 마지막 단계입니다. 계정을 연결하고, POST /connected-accounts/trigger-matches를 실행하여 제안을 생성하고, 연결 제안 엔드포인트로 제안을 검토한 다음, 여기에서 승인된 레코드를 확정합니다.

사용 사례: 검토한 매칭 일괄 수락. 대행사가 고객의 Google 계정을 가져오고 직접 구축한 UI에서 추천된 쌍을 검토한 후, 매칭마다 개별적으로 호출하는 대신 승인된 matchRecordIds를 한 번의 호출로 제출합니다. 검토하지 않았거나 잘못된 제안은 그대로 유지되도록 운영자가 승인한 ID만 전송합니다.

매칭을 확정해도 Google 또는 Facebook에 데이터가 즉시 전송되지는 않으며, Listings API 사업장을 게시 플랫폼의 등록 정보에 연결하여 이후 등록 정보 업데이트가 전달되도록 합니다. 호출이 성공하면 failedIds: null과 함께 success: true를 반환합니다. 1개 이상의 ID를 확정할 수 없는 경우(예: 알 수 없거나 이미 사용된 매칭 레코드, 또는 해당 사업장이 이후에 보관 처리된 매칭), 해당 ID가 failedIds에 반환되고 success는 false가 되므로 재시도하거나 실패한 항목만 표시할 수 있습니다. failedIds에는 전송한 인코딩된 값이 아니라 디코딩된 데이터베이스 ID가 포함되므로, 이를 matchedDataDatabaseId와 대조하여 매칭합니다. 제안을 거치지 않고 등록 정보 1개를 수동으로 선택하려면 대신 등록 정보 연결 엔드포인트를 사용합니다.