개발자

PUT/tcr/v2/brand/{brandId}/externalVetting

기존 심사 결과 가져오기

지원되는 제공업체의 기존 심사 결과를 브랜드에 연결합니다.

이 페이지의 내용
  1. 계정 소유의 메시징 브랜드 사용
  2. 제공업체의 기존 결과 사용
  3. 가져오기 준비
  4. 결과를 한 번만 가져오기
  5. 기존 청구 이해
  6. 실제 심사 결과 확인
  7. 동일한 작업의 요청 재시도

계정 소유의 메시징 브랜드 사용

허용된 출발지 IP에서 HTTPS를 통해 활성화된 API 계정을 사용하세요. Basic 및 Bearer 인증을 지원합니다. 브랜드 ID는 해당 계정에 속해야 합니다. 제공업체 토큰, 브랜드 식별 정보 및 반환된 보고서는 비공개로 관리하세요.

제공업체의 기존 결과 사용

PUT 메서드를 사용하여 지원되는 제공업체의 기존 심사 결과를 브랜드에 연결하세요. 이 작업은 새 심사를 주문하지 않습니다. 올바른 제공업체 거래 ID와 필요한 확인 토큰을 해당 제공업체로부터 직접 받고, 보고서가 동일한 사업체에 대한 것인지 확인하세요.

AUTHPLUS는 이 가져오기 절차를 지원하지 않습니다. 제공업체별 일치 확인 규칙은 계속 적용됩니다. 가져오기 요청이 이러한 규칙을 면제하거나 모든 캠페인 용도에 대한 자격을 보장하지는 않습니다.

가져오기 준비

외부 심사 결과 가져오기 필드
필드값
evpId지원되는 제공업체 ID로, 길이는 1–10자입니다.
vettingId제공업체의 실제 심사 거래 식별자로, 최대 255자입니다. 브랜드 ID로 대체하거나 식별자를 임의로 만들지 마세요.
vettingToken제공업체에서 요구하는 경우에 사용하는 확인 토큰으로, 최대 65535자입니다. 비밀 정보로 취급하고, 제공업체에서 요구하지 않으면 생략하세요.

제공업체의 실제 값을 사용하여 vetting-import.json을 만드세요. 응답 전용인 점수, 상태 또는 타임스탬프 필드로 결과를 변경할 수 있는 것처럼 해당 필드를 전송하지 마세요.

결과를 한 번만 가져오기

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  --request PUT \
  --header 'Content-Type: application/json' \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  --data-binary @vetting-import.json \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID/externalVetting"

기존 청구 이해

이 프록시는 새로 가져온 결과를 새로운 유료 주문으로 기록하지 않습니다. 그렇다고 이전에 주문한 심사가 취소되는 것은 아닙니다. 동일한 vettingId에 결과 대기 또는 과금 대기 중인 주문이 이미 있는 경우, ACTIVE 또는 FAILED 결과를 가져오면 해당 주문에 저장된 요금이 정산될 수 있습니다. 이 동기화 분기에서는 이미 과금된 기록에 다시 과금하지 않습니다.

실제 심사 결과 확인

성공한 HTTP 응답에도 대기 중인 심사 기록이 포함될 수 있습니다. 해당 vettingId를 보관하고, 제공되는 범위에서 vettingStatus, 사유, 점수 및 유효 시작일과 만료일을 확인하세요. PENDING 및 UNSCORE는 추가적인 확인이 필요하며, ACTIVE, FAILED 및 EXPIRED는 서로 다른 결과를 나타냅니다. HTTP 요청이 수락되었다는 사실만으로 유리한 점수나 캠페인 자격이 입증되지는 않습니다.

기록을 추적하려면 다음 항목을 사용하세요: 외부 심사 상태. 최종 상태의 결과를 조회하거나 가져오면 이전 유료 주문이 정산될 수 있습니다. 기존 미납 요금이 청구되지 않는다고 보장할 수는 없습니다.

동일한 작업의 요청 재시도

수행하려는 작업마다 Idempotency-Key 하나를 사용하고 메서드, 경로, 쿼리 및 본문의 바이트를 정확히 그대로 유지하세요. 키에는 공백 없이 출력 가능한 ASCII 문자 1–128자를 사용할 수 있습니다. 진행 중인 요청과 중복되는 요청은 Retry-After와 함께 409를 반환할 수 있습니다. 완료된 요청은 오류를 포함하여 저장된 응답을 다시 반환합니다. 요청 빈도 제한을 준수하세요.

전송 실패 후 캐시된 502가 반환될 수 있습니다. requestId가 포함된 캐시된 500은 레지스트리가 작업을 수락했지만 로컬 영구 저장 또는 과금이 실패했음을 의미할 수 있습니다. 요청 ID를 보관하고 현재 기록을 확인한 뒤, 새 키를 사용하기 전에 지원팀과 내역을 대조하여 정리하세요. 오류가 발생했다고 해서 주문이 존재하지 않는다고 가정하지 마세요.