수신 payload
게이트웨이가 여러분의 URL로 보내는 요청의 형식입니다.
요청
POST <내 웹훅 URL>
Content-Type: application/json
X-Bridge-Signature: v0=<hex>
X-Bridge-Event: <kind>
X-Bridge-Timestamp: <unix seconds>
X-Bridge-Delivery-Id: <uuid>
바디 — "신호"
{
"brand": "mybrand",
"userKey": "Ab3d_x9Kq2Lm",
"kind": "message",
"seq": 42
}
| 필드 | 타입 | 설명 |
|---|---|---|
brand | string | 브랜드(채널) 키 |
userKey | string | 상담 고객 키. 발신 API의 userKey와 동일한 상관키 |
kind | string | 이벤트 종류(아래 표) |
seq | number | 브랜드 저널의 단조증가 시퀀스. 순서·멱등 판단 기준 |
payload는 "무슨 일이 있었다"는 신호이며 메시지 본문(text)을 포함하지 않습니다.
실제 대화 내용이 필요하면 수신 내용 조회 API로 가져오세요. 헤더 X-Bridge-Event는 바디의 kind와 동일합니다.
이벤트 종류 (kind)
kind | 의미 | 일반적 처리 |
|---|---|---|
message | 고객이 메시지를 보냄 | 본문 조회 → 처리/답장 |
reference | 새 상담이 연결됨(세션 시작) | 세션 시작 처리 |
expired | 세션이 만료됨 | 세션 종료 처리 |
ended | 상담이 종료됨 | 세션 종료 처리 |
agent | 여러분(또는 상담사)의 발신이 반영됨(echo) | 보통 무시 |
deleted | 보낸 메시지가 삭제됨(발신 취소) — serial 로 어떤 발신인지 대조 | 내 화면의 해당 말풍선을 삭제 표시 |
personal_info | 고객이 개인정보 제공에 동의함 — 값이 바디에 실려 옵니다(아래) | 즉시 보관 |
kind: "agent" 는 여러분이 보낸 발신이 되돌아온 echo입니다. 답장 로직이 이 이벤트에 반응하면 무한 루프가 됩니다 — agent는 걸러내세요.
agent echo 는 두 번 옵니다
발신 1건마다 kind: "agent" 신호가 두 번 도착합니다. 둘은 필드로 구분합니다 — seq 유무로 추정하지 마세요.
| 순서 | 언제 | 구분 필드 | 내용 |
|---|---|---|---|
| ① 접수 신호 | 발신 API 가 성공을 돌려준 직후 | phase: "accepted" · serial | seq 없음. 발신 응답의 serial 과 같은 값 — 낙관적으로 그린 말풍선과 정확히 매칭할 수 있습니다 |
| ② 저널 항목 | 약 1초 뒤, 브랜드 저널에 기록된 시점 | seq · serial | 다른 이벤트와 같은 형식. 멱등 키 (brand, seq) 에 포함됩니다. 여러 말풍선으로 나간 첨부 발신은 serials 에 전체 목록이 함께 옵니다 |
{ "brand": "mybrand", "userKey": "Ab3d_x9Kq2Lm", "kind": "agent", "phase": "accepted", "serial": "bw-1757400000000-a1b2" }
{ "brand": "mybrand", "userKey": "Ab3d_x9Kq2Lm", "kind": "agent", "seq": 43, "serial": "bw-1757400000000-a1b2" }
권장 처리: ①은 저장하지 않고 UI 확인(ack)에만 쓰고, ②는 seq 로 멱등 처리합니다. 둘 다 무시해도 상담 흐름에는 영향이 없습니다. ①에 serial 이 없을 수 있는 경우(옛 코어)도 phase 는 항상 있습니다.
메시지 삭제 (deleted)
발신 취소(삭제)가 성공하면 kind: "deleted" 신호가 옵니다. serial 은 지운 발신의 serial 이라, 위 agent 신호나 발신 응답의 serial 과 대조하면 어떤 말풍선인지 알 수 있습니다.
{ "brand": "mybrand", "userKey": "Ab3d_x9Kq2Lm", "kind": "deleted", "seq": 45, "serial": "bw-1757400000000-a1b2" }
삭제를 요청한 쪽이 아니어도(예: 같은 브랜드를 쓰는 다른 상담 도구) 이 신호로 화면을 맞출 수 있습니다. 다른 이벤트와 같이 (brand, seq) 로 멱등 처리하세요. 삭제해도 상담 건수는 되돌아오지 않습니다.
개인정보 제공 동의 (personal_info)
개인정보 제공 동의 요청에 고객이 동의하면 옵니다. 다른 신호와 달리 값이 바디에 실려 있습니다.
{
"brand": "mybrand", "userKey": "Ab3d_x9Kq2Lm", "kind": "personal_info",
"sessionId": "29153", "consentedAt": 1757400000000,
"personalInfo": { "phoneNumber": "821012345678", "nickname": "고객닉네임" }
}
| 필드 | 설명 |
|---|---|
sessionId | 동의가 일어난 카카오 상담 세션 |
consentedAt | 고객이 동의한 시각(Unix ms) |
personalInfo.phoneNumber | 카카오계정 전화번호(국가번호 포함, 예: 8210…). 카카오에 등록되지 않았으면 빈 문자열 |
personalInfo.nickname | 카카오 프로필 닉네임. 등록되지 않았으면 빈 문자열 |
seq가 없습니다. 브랜드 저널에 기록하지 않는 신호라 멱등 키(brand, seq)대신X-Bridge-Delivery-Id로 중복을 거르세요.- TalkBridge 는 이 값을 저장하지 않고 전달만 합니다. 수신 내용 조회에도 나오지 않고, 다시 받을 방법이 없습니다. 웹훅이 응답하지 않으면 잠시 재시도한 뒤 폐기합니다 — 받은 즉시 보관하세요.
- 이 정보의 보관·이용·파기는 귀사가 책임집니다. 귀사 개인정보 처리방침에 수집 항목과 목적을 안내하세요.
- 디스코드·슬랙 연동에는 "고객이 개인정보 제공에 동의했습니다" 알림만 가고 값은 가지 않습니다.
상담 연결 메타 (extra)
상담 연결 버튼·링크나 챗봇 전환에 심은 값(extra)은 신호에 그대로 실려 옵니다. 값이 있을 때만 필드가 생깁니다.
kind | 필드 | 내용 |
|---|---|---|
reference | reference.extra | 이번 상담 연결에 심은 값 |
reference | lastReference.{extra, bot, botEvent, createdAt} | 이번 값이 없을 때 카카오가 알려 주는 가장 최근 메타 |
message | extra | 고객이 버튼(BK/MD)을 눌러 보낸 메시지의 값 |
{ "brand": "mybrand", "userKey": "Ab3d_x9Kq2Lm", "kind": "reference", "seq": 44, "reference": { "extra": "goods_1024" } }
심는 방법·읽는 순서·라우팅 예제는 상담 연결 메타 활용을 보세요.
테스트 신호
톡브릿지 센터 개발자 모드 「연결 테스트」의 수신 테스트는 실제 전달과 같은 헤더·같은 서명으로 아래 신호를 보냅니다.
{ "brand": "mybrand", "userKey": "tb-test-1a2b3c4d", "kind": "message", "seq": 0, "test": true }
test: true는 테스트 신호에만 붙습니다. 실제 신호에는 이 필드가 없습니다.userKey는 가상 고객(tb-test-로 시작)이라 본문 조회·답장이 되지 않습니다. 서명 검증과 2xx 응답까지만 확인하고, 저장·답장 로직은 건너뛰세요.seq는 항상0이라 멱등 키(brand, seq)에 걸릴 수 있습니다 —test: true면 멱등 처리 전에 분기하세요.