상담톡 연동 진행중에 문의드립니다

안녕하십니까. 상담톡 연동 진행 중 확인이 필요한 사항이 있어 문의드립니다.

현재 수신·발신 모두 정상 동작 중이며, 웹훅 URL 등록도 정상으로 확인했습니다.
(최근 12시간 기준 조선팔도떡집 문의는 조선팔도 URL로, 오트메딘 문의는 오트메딘
URL로 각각 정확히 수신되고 있습니다. 정정해 주신 것으로 보입니다. 감사합니다.)

아래는 추가 확인이 필요한 항목입니다.

────────────────────────────────────────────────────────

  1. 개인정보 수신(personal_info) 웹훅이 오지 않습니다 ★ 가장 급합니다
    ────────────────────────────────────────────────────────

활성화 이후 수신된 requestType을 전수 집계한 결과입니다.

message          36건
write            31건
seen_info        27건
reference        11건
personal_info     0건   ← 한 건도 없습니다

개발 가이드에는 personal_info / msgType=PERSONAL 로 고객의 phone_number와
nickname이 전달된다고 되어 있으나, 실제로는 한 건도 수신되지 않았습니다.

여쭙습니다.

(1) personal_info 수신은 별도 신청이 필요한 항목입니까?
필요하다면 신청 절차를 알려주십시오.

(2) 고객 동의는 어느 화면에서 받습니까?
자동으로 뜨는 것입니까, 아니면 당사가 동의 요청 API를 호출해야 합니까?
(네이버 톡톡은 별도의 프로필 동의 요청 API가 있어, 요청해야만 동의창이 뜹니다)

(3) 동의가 완료되면 phone_number가 마스킹 없이 전체 번호로 전달되는 것이
맞습니까?

배경을 덧붙이면, 상담 문의를 주문 내역과 자동으로 대조하려면 고객 식별이
필요합니다. 지금은 고객이 직접 알려준 정보에만 의존하고 있어, 동명이인이나
번호 일부 일치로 상담사가 매번 수기 확인을 하고 있습니다.

────────────────────────────────────────────────────────
2. 발송결과 reportCode 규격 확인
────────────────────────────────────────────────────────

당사 발신에 대한 write 웹훅에서 아래 값을 수신했습니다.
고객에게는 정상 도착했습니다.

requestType : write
reportCode  : 10000
ref         : 403
senderKey   : 1c5b48dc...
serviceType : CSTALK

공개 문서의 reportCode 표(/api-sdk/api-reference/error-codes)에는 공통 코드
1000(발송 성공)까지만 기재되어 있고, 상담톡 체계는 없습니다.

(1) 상담톡 write의 성공 코드가 10000이 맞습니까?

(2) 상담톡 전용 reportCode 전체 표를 제공해 주실 수 있습니까?
실패 코드를 모르면 재발송 판단을 자동화할 수 없습니다.

────────────────────────────────────────────────────────
3. 활성화 API 문서 보완 요청 (참고)
────────────────────────────────────────────────────────

연동 과정에서 개발 가이드와 실제 동작이 달라 시행착오가 있었습니다.
문서 보완에 참고해 주시면 감사하겠습니다.

(1) committalCompany
문서 : “선택(No). 사전 등록 시 생략 가능”
실제 : 사전 등록이 없으면 필수. 생략하면 A213 반환

(2) 에러코드 A213
문서 : 공개 에러코드 표에 없음
실제 : “상담톡을 사용하기 위해서는 반드시 위탁사명을 입력해야 합니다”

(3) 상담시간 저장 요청 필드
문서 : weekTimeTable (대문자 T)
실제 : weekTimetable (소문자 t)
대문자로 보내면 “weekTimetable is empty” 로 거부됩니다.
특히 이 항목은 조회 응답이 대문자 weekTimeTable로 돌아와서,
문서와 조회 결과만 보면 원인을 찾기가 어려웠습니다.

(4) 상담시간 종료 시각
문서 : HHMM
실제 : 2400은 “Invalid time format”. 2359를 사용해야 합니다.

────────────────────────────────────────────────────────
4. Rate limit 한도
────────────────────────────────────────────────────────

활성화 API를 연속 호출하는 과정에서 A020(Ratelimit 초과)을 받았습니다.
공개 문서에 구체적인 TPS 수치가 없습니다.

API 군별 호출 한도를 알려주시면 당사 호출 간격 설계에 반영하겠습니다.

────────────────────────────────────────────────────────

바쁘신 중에 감사합니다.

안녕하세요. 비즈고를 이용해주셔서 감사합니다.

상세하게 확인해 주신 내용과 함께 문의 남겨주셔서 감사드립니다.

문의하신 항목별로 아래와 같이 답변드립니다.

1. 개인정보 수신(personal_info) 웹훅

personal_info 웹훅은 고객이 동의를 완료해야 발생하는 이벤트로, 자동으로 수신되지 않습니다. 수신 흐름은 다음과 같습니다.

발신 측에서 rich 타입 메시지 중 personal 타입으로 발송
고객의 채팅방에 개인정보 수집·이용 동의 팝업이 표출
고객이 팝업에서 동의를 선택한 시점에 personal_info 웹훅 수신

문의하신 세 가지에 대해 정리하면 아래와 같습니다.

(1) 별도 신청이 필요한가?
별도 신청은 필요하지 않습니다. 다만 위 흐름과 같이 personal 타입 메시지를 발송하셔야 동의 절차가 시작됩니다.

(2) 고객 동의는 어느 화면에서 받는가?
자동으로 표출되지 않습니다. 말씀해 주신 네이버 톡톡의 프로필 동의 요청과 유사하게, 고객사에서 personal 타입 메시지를 발송해야 고객 화면에 동의 팝업이 표출되는 구조입니다. 현재 personal_info가 0건인 것은 해당 타입 발송 이력이 없기 때문으로 판단됩니다.

(3) 동의 후 phone_number 형식은?
마스킹 없이 전체 번호가 그대로 전달됩니다.

말씀하신 주문 내역 자동 대조 목적이라면, 상담 인입 초기에 personal 타입 메시지를 발송해 동의를 받는 흐름으로 설계하시는 것을 권해 드립니다.

2. 발송결과 reportCode 규격

(1) 성공 코드 10000이 맞는지?
네, 맞습니다. 상담톡은 공통 코드 체계(1000번대)가 아닌 별도의 10000번대 체계를 사용합니다.

(2) 상담톡 전용 reportCode 전체 표

[리포트 코드 > 10000번대를 제외한 6으로 시작하는 코드가 상담톡 전용 리포트 코드입니다]

더불어 한 가지 확인 부탁드립니다. 문의 주신 내용 중 참고하신 문서가 공통 에러코드 표(/api-sdk/api-reference/error-codes) 외에 추가로 있으신지 알려주시면, 해당 문서 기준으로 상담톡 체계와의 차이를 정확히 확인하여 안내드리겠습니다.

3. 활성화 API 문서 보완 요청

꼼꼼하게 확인해 주셔서 감사합니다.

알려주신 4개 항목 모두 실제 동작과 문서 간 차이가 확인되는 부분으로,

규격서에 반영하여 수정하겠습니다.

항목 내용
committalCompany 사전 등록이 없는 경우 필수 — 필수 조건 명시 예정
에러코드 A213 공개 에러코드 표에 추가 예정
weekTimetable 요청 필드 표기 정정 예정 (소문자 t)
상담시간 종료 시각 2400 미지원 — 사용 가능 범위 명시 예정

특히 weekTimetable은 요청 필드는 소문자 t, 조회 응답은 대문자 T로 반환되어 원인 파악에 어려움이 있으셨던 만큼, 해당 부분도 함께 검토하겠습니다.

4. Rate limit 한도

API 군별 호출 한도는 아래와 같습니다.

구분 한도
발송 API 200 TPS
관리 API (활성화, 상담시간 저장·조회 등) 5 TPS

받으셨던 A020(Ratelimit 초과)은 활성화 API가 관리 API 군(5 TPS) 에 해당하여 기준을 초과한 경우로 판단됩니다. 호출 간격 설계 시 참고 부탁드립니다.

추가로 궁금하신 사항이 있으시면 언제든 문의 남겨주세요.
감사합니다.