개발자

PUT/tcr/v2/brand/{brandId}

메시징 브랜드 업데이트

기존 등록을 유지하고 검증 상태를 확인하면서 사업자 정보와 연락처 정보를 수정합니다.

이 페이지의 내용
  1. 기존 메시징 브랜드 수정
  2. 현재 브랜드 필드 유지
  3. 검토한 수정 사항 제출
  4. 저장된 레코드와 검증 상태 확인
  5. 중복 등록 없이 오류 해결

기존 메시징 브랜드 수정

사업자 연락처 정보나 주소가 변경되면 기존 브랜드를 업데이트하세요. 브랜드 ID는 유지해야 합니다. 기존 사업자 정보를 수정하기 위해 별도의 등록을 생성해서는 안 됩니다. 허용된 출발지 IP 주소에서 활성화된 API 계정을 사용하여 HTTPS로 접속하세요. 해당 브랜드는 그 계정에 속해야 합니다.

먼저 현재 레코드를 조회하세요. 사업자 식별 정보와 연락처 정보가 포함되어 있으므로 로컬 사본은 비공개로 보관하세요.

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID" \
  --output current-brand.json

현재 브랜드 필드 유지

현재 레코드에서 쓰기 가능한 브랜드 필드만 선택하여 brand-update.json을 준비하세요. 원하는 수정 사항을 적용하면서 사업자 식별 정보와 기타 필수 값은 유지하세요. GET 응답 전체를 보내지 마세요. brandId, 신원 확인 및 상태 결과, 타임스탬프 등 응답 전용 필드는 업데이트에 포함하면 안 됩니다.

업데이트 스키마에서는 entityType, displayName, country, email, brandRelationship이 필수입니다. 사업 주체 유형별 규칙도 계속 적용됩니다. 조직의 경우 해당되는 법적 회사명, 납세자 식별 번호와 발급 국가, 주소 및 업종을 유지하세요. 개인 사업자의 경우에는 대신 해당하는 개인 이름 및 휴대전화 연락처 필드를 유지하세요. 등록 예제의 자리표시자 대신 실제 현재 값을 사용하세요.

브랜드 업데이트 필드 그룹
필드사용 방법
displayName, email, phone쉽게 알아볼 수 있는 브랜드 이름과 유효한 연락처 정보입니다. 최대 길이는 각각 255, 100, 20자입니다. 전화번호는 + 뒤에 국가 코드를 붙이는 국제 형식을 사용하세요.
street, city, state, postalCode, country각 항목이 서로 일치하는 실제 사업장 주소입니다. 길이 제한은 각각 255, 100, 20, 10, 2자입니다. 해당하는 경우 현행 미국 주 코드를 사용하세요.
entityType, companyName, ein, einIssuingCountry법적 사업자 식별 정보입니다. 캠페인이나 외부 심사가 대기 중이거나 활성 상태인 경우 이 정보의 변경이 제한됩니다. 식별 정보 변경 제한을 우회하려는 목적으로 운영 중인 캠페인을 삭제하지 마세요.
firstName, lastName, mobilePhone, businessContactEmail사업 주체 유형에 따라 필요한 식별 정보 또는 확인용 연락처입니다. 길이 제한은 각각 100, 100, 20, 255자입니다.
brandRelationship, vertical현재 관계 유형 및 업종 코드입니다. 관계 유형 변경은 삼 개월에 한 번으로 제한됩니다. 포털의 일반 편집 양식에서는 관계 유형을 변경할 수 없습니다.
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange해당하는 웹사이트, 대체 사업자 식별 정보 및 상장 기업 정보입니다. 사업 주체의 검증에 필요한 값을 유지하세요.
referenceId, ipAddress지원되는 사업자 참조 정보 및 출발지 IP 메타데이터입니다. 어느 것도 계정 소유 관계를 설정하거나 요청의 멱등성 키 역할을 하지 않습니다.

코드는 최신 메시징 카탈로그를 참조하세요. 업데이트 스키마는 브랜드 환경을 변경하는 수단으로 mock 항목을 제공하지 않습니다. 편집 시 이 플래그를 변경하지 말고, 별도로 검토된 샌드박스에서 프로덕션으로의 전환 절차를 사용하세요.

검토한 수정 사항 제출

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 @brand-update.json \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID"

이번 업데이트에는 하나의 키를 사용하고 요청 본문의 바이트를 정확히 그대로 보관하세요. 메서드, 경로, 쿼리 또는 본문을 변경한 상태에서 같은 키를 재사용하면 충돌이 발생합니다. JSON의 서식만 바꿔도 지문이 변경됩니다. 처리 중인 요청과 중복되는 요청은 Retry-After와 함께 409를 반환할 수 있습니다. 완료된 요청은 오류를 포함하여 저장된 결과를 다시 반환할 수 있습니다. 시간 초과 후 처리 결과를 확인할 때는 새 키를 자동으로 생성하지 말고 요청 세부 정보를 보관하세요.

저장된 레코드와 검증 상태 확인

업데이트가 성공하면 HTTP 200과 브랜드 JSON 객체를 직접 반환하며, 기존 v3의 status/response 래핑 구조는 사용하지 않습니다. brandId를 확인한 다음 같은 브랜드를 GET으로 다시 조회하여 수정 대상 필드를 비교하세요. 공개 업데이트 경로는 포털의 changes/version 래퍼를 받지 않으며 포털의 낙관적 동시성 검사도 제공하지 않습니다. 동시에 편집하는 담당자끼리 조율하세요. 멱등성 키는 중복 제출을 방지하지만 다른 편집자의 변경을 막지는 않습니다.

현재 포털은 브랜드를 조회하고 쓰기 가능한 필드를 유지하며, 저장 전에 양식 버전을 확인한 후 결과를 다시 조회합니다. 활성 캠페인이 발견되면 핵심 법적 사업자 식별 필드를 잠급니다. 양식에서 입력할 수 있었던 필드라도 등록 기관이 외부 심사 관련 제한을 비롯한 추가 제한을 적용할 수 있습니다.

수정한 정보를 저장해도 새로운 신원 확인이 자동으로 요청되거나 승인이 보장되지는 않습니다. 재검증은 별도의 작업이며 수수료가 발생할 수 있습니다. 포털에서 현재 상태를 검토하고 제시된 요금이 있다면 명시적으로 승인하세요. 일반적인 브랜드 PUT 업데이트는 현재 API 서비스에서 별도의 등록 요금 차감을 발생시키지 않습니다. 기존 캠페인, 메시징 및 기타 요금은 계속 별도로 처리됩니다.

중복 등록 없이 오류 해결

HTTP 상태와 JSON 오류 세부 정보를 확인하세요. 400이면 해당 필드를 수정하거나 식별 정보 및 관계 유형 변경 제한을 준수하세요. 401, 403 또는 404이면 인증 정보, 허용된 출발지 IP 및 계정 소유 관계를 확인하세요. 429이면 Retry-After를 따르세요. 등록 기관이 업데이트를 수락한 뒤에도 500 또는 502가 발생할 수 있습니다. requestId가 있다면 보관하고, 다시 제출하기 전에 기존 레코드를 조회하세요.

업데이트 응답이 비어 있지 않더라도 불완전하면 로컬 스냅샷이 불완전하게 남을 수 있습니다. 성공 응답의 본문이 비어 있으면 스냅샷의 이전 필드가 남을 수 있습니다. 성공 상태만 보고 필드가 유지되었다고 판단하지 마세요. 전체 브랜드 정보를 다시 조회하고, 불일치가 있으면 지원팀을 통해 해결하세요. 이 가이드는 등록 기관, 로컬 캐시 및 과금 정보의 업데이트가 원자적으로 이루어진다고 보장하지 않습니다.