Session.ApproverEmailUpdate
보호자가 k-ID 계정의 이메일 주소를 변경할 때, 해당 주소가 동의를 제공하는 자녀마다 한 번씩 발생합니다. 페이로드에 변경 전과 변경 후 주소가 모두 포함되므로, 서버는 이 이벤트만으로 이미 보관 중인 레코드를 찾아 갱신할 수 있습니다.
세션은 그 외에는 달라지지 않습니다. ACTIVE 상태를 유지하고 동일한 sessionId와 권한을 그대로 가지며, 자녀는 중단 없이 계속 이용할 수 있습니다. 바뀌는 것은 k-ID가 해당 자녀의 이후 챌린지, 승인, 알림을 보내는 주소뿐입니다.
이 이벤트를 구독하세요
웹훅 엔드포인트는 구독한 이벤트 타입만 수신합니다. Compliance Studio에서 해당 프로덕트의 Developer Settings 페이지에 들어가 엔드포인트에 Session.ApproverEmailUpdate를 선택하세요. 선택하지 않으면 k-ID는 전송을 시도하지도, 오류를 반환하지도 않고 이벤트를 폐기합니다. 이 항목은 조직에서 보호자 이메일 변경이 활성화된 경우에만 목록에 표시됩니다.
전송과 재시도
웹훅 이벤트는 실패 시 최대 2회 재시도됩니다. 자세한 내용은 전송, 재시도, 복구를 참고하세요.
발생 시점
보호자는 Family Connect에서 이메일 변경을 시작하고, 새 주소로 전송된 일회용 코드로 확인합니다. 변경을 확정하면 k-ID는 각 자녀의 세션을 새 주소로 다시 연결하고, 자녀 세션마다 Session.ApproverEmailUpdate를 하나씩 발생시킵니다.
- 자녀별, 프로덕트별로 한 건. 보호자에게 귀사 프로덕트 내 자녀가 셋이라면 이벤트도 세 건이 발생하며, 각각 서로 다른
id와 동일한oldEmail,newEmail을 갖습니다. - 활성 세션이 있는 자녀만 해당됩니다. 귀사 프로덕트에 활성 세션이 없는 자녀는 다시 연결할 대상이 없으므로 이벤트가 발생하지 않습니다. 그 자녀가 이후에 세션을 갖게 되면, 그 세션은 새 주소를 기준으로 생성됩니다.
- 확정은 한 번만 발생시킵니다. k-ID는 승인자가 여전히
oldEmail인 세션만 다시 연결하므로, 확정을 재시도해도 이미 이전된 자녀에 대해 두 번째 이벤트가 발생하지 않습니다. 다만 전송은 최소 1회 보장이므로 핸들러는 멱등하게 유지하세요.
필드
| 필드 | 타입 | 필수 | 설명 |
|---|---|---|---|
eventType | string | 예 | 항상 "Session.ApproverEmailUpdate" |
data | object | 예 | 이메일 변경 정보 |
data.id | string (UUID) | 예 | 귀사 프로덕트에 있는 해당 자녀 세션의 세션 ID |
data.productId | number | 예 | 해당 프로덕트의 productId |
data.oldEmail | string | 예 | 보호자가 변경 전에 사용하던 주소 |
data.newEmail | string | 예 | 보호자가 변경 후 사용하는 주소이며, k-ID는 이후 해당 자녀의 이메일을 이곳으로 보냅니다 |
예시
{
"eventType": "Session.ApproverEmailUpdate",
"data": {
"id": "2d064cf7-0726-4193-b19a-8bd387937e60",
"productId": 12345,
"oldEmail": "parent@example.com",
"newEmail": "new.parent@example.com"
}
}
이벤트 처리
data.id로 대조하세요. 변경이 적용되는 세션이며, 세션이 다시 만들어지지는 않고 그 뒤의 주소만 옮겨지므로 변경 전후로 동일하게 유지됩니다.data.oldEmail은 세션을 조회하는 용도가 아니라, 의도한 레코드를 갱신하고 있는지 확인하는 용도로 사용하세요.- 해당 자녀에 대해 저장해 둔 보호자 이메일 주소를 갱신하고, 플레이어나 보호자에게 표시하는 모든 위치도 함께 갱신하세요.
- 자녀를 동의 절차로 되돌려 보내지 마세요. 해당 세션이 보유한 승인은 변경되지 않았고, 권한도 보호자가 설정한 그대로 유지됩니다.
- 동일한 이벤트가 두 번 이상 도착할 수 있다고 가정하세요. 전송은 최소 1회 보장이므로 핸들러를 멱등하게 작성하고, 이미 적용한
newEmail을 담은 이벤트는 아무 동작도 하지 않아야 합니다. - 프로덕트가 세션이 아니라 보호자 이메일 주소를 키로 사용하는 부분이 있다면, 그 키가 낡지 않게 막아 주는 것이 바로 이 이벤트입니다. 더 견고한 방식은 세션을 키로 삼고 이메일 주소는 거기에 딸린 데이터로 다루는 것입니다. 모범 사례를 참고하세요.