연결 제안 목록 조회

연결된 계정에서 매칭 트리거를 실행하여 감지한 Listings API 사업장과 Google Business Profile 또는 Facebook 등록 정보 간의 연결 제안을 반환합니다. 각 레코드에는 Listings API 사업장 세부 정보와 매칭된 게시 플랫폼 등록 정보가 모두 표시되므로 운영자가 확정 전에 비교할 수 있습니다.

제안은 POST /connected-accounts/trigger-matches에 의해 비동기적으로 생성됩니다. 계정을 방금 연결했다면 먼저 trigger-matches를 호출해야 하며, 그렇지 않으면 records는 비어 있고 pageInfo.totalRecords는 0입니다. (아직 매칭 결과가 없는 새로 연결된 계정을 대상으로 실제 호출하면 이 엔드포인트는 {"data":{"connectionSuggestionsForAccount":{"pageInfo":{"hasNextPage":false,"hasPreviousPage":false,"totalPages":0,"totalRecords":0},"records":[]}}}를 반환합니다.) 위 예시는 데이터가 채워진 레코드의 구조를 보여 줍니다.

사용 사례: 검토 후 확정 워크플로. 고객의 Google 계정을 가져온 후 이 엔드포인트를 폴링하여 자체 검토 UI에 모든 매칭 제안을 표시합니다. 운영자가 올바른 연결을 승인하면 승인된 레코드 ID를 POST /connected-accounts/confirm-matches에 전달합니다.

레코드 식별. 제안 레코드에는 id 필드가 없습니다. 식별자는 기반 매칭 레코드의 기본 키인 matchedDataDatabaseId이며, accountType은 매칭 레코드의 유형(GMB, FB 또는 APPLE)을 나타냅니다. 매칭 확정에는 입력으로 받는 id를 구성하기 위해 두 값이 모두 필요하므로, 검토용으로 제안을 정리할 때 두 값을 함께 보관합니다.

페이지네이션 및 요청 빈도 제한. 중첩되지 않은 page 및 perPage 쿼리 매개변수(예: ?page=2&perPage=50)로 페이지를 지정하고 pageInfo.hasNextPage를 확인합니다. pageInfo, filters, sortBy 또는 accountId 매개변수는 없으며, 연결된 계정은 경로에서 결정되고, 정렬 순서는 사업장 정보의 오름차순으로 고정되며, 그 외에 전송하는 매개변수는 거부되지 않고 무시됩니다. 이 엔드포인트에는 다른 목록 조회 엔드포인트와 마찬가지로 요청 빈도 제한이 적용되므로, 429를 받으면 폴링 간격을 줄이지 말고 요청을 늦춘 뒤 Retry-After 헤더 값에 지정된 시간이 지나면 다시 시도합니다.