Session.ApproverEmailUpdate

Emitted when a parent changes the email address on their k-ID account, once for each child whose consent that address approves. The payload carries both the old and the new address, so your server can find the record it already holds and update it from the event alone.

The session isn't changed in any other way. It stays ACTIVE, keeps the same sessionId and permissions, and the child carries on uninterrupted. Only the address k-ID sends that child's future challenges, approvals, and notifications to has moved.

Subscribe to this event

A webhook endpoint receives only the event types it's subscribed to. Select Session.ApproverEmailUpdate for your endpoint on the product's Developer Settings page in Compliance Studio, or k-ID drops the event without a delivery attempt or an error. It's listed only once parent email change is enabled for your organization.

Delivery and retries

Webhook events are retried up to 2 times on failure. See Delivery, retries, and recovery for details.

When it fires

A parent starts an email change from Family Connect and confirms it with a one-time code sent to the new address. When they commit the change, k-ID moves each of their children's sessions to the new address and emits one Session.ApproverEmailUpdate per child session.

• One event per child, per product. A parent with three children in your product produces three events, each carrying a different id and the same oldEmail and newEmail.
• Only children who have an active session. A child with no active session in your product has nothing to move, so no event fires for them. If that child later gets a session, it's created against the new address.
• Committing the change fires once. k-ID only moves a session whose approver is still oldEmail, so a retried commit doesn't emit a second event for a child already moved. Delivery is still at-least-once, so keep your handler idempotent.

Fields

Field	Type	Required	Description
eventType	string	yes	Always "Session.ApproverEmailUpdate"
data	object	yes	Email change details
data.id	string (UUID)	yes	Session ID for the child's session in your product
data.productId	number	yes	The productId for the product
data.oldEmail	string	yes	The address the parent moved away from
data.newEmail	string	yes	The address the parent moved to, and where k-ID now sends that child's emails

Example

{
  "eventType": "Session.ApproverEmailUpdate",
  "data": {
    "id": "2d064cf7-0726-4193-b19a-8bd387937e60",
    "productId": 12345,
    "oldEmail": "parent@example.com",
    "newEmail": "new.parent@example.com"
  }
}

Handling the event

• Match on data.id. It's the session the change applies to, and it's stable across the change: the session isn't recreated, only the address behind it moves. Use data.oldEmail to confirm you're updating the record you think you are, not to look the session up.
• Update the parent email you store against that child, and update it anywhere you display it back to the player or the parent.
• Don't send the child back through consent. The approval that session holds is unchanged, and the permissions on it stay exactly as the parent left them.
• Expect the same event more than once. Deliveries are at-least-once, so write the handler to be idempotent: an event whose newEmail you've already applied should be a no-op.
• If your product keys anything on the parent's email rather than on the session, this event is what keeps that key from going stale. The more durable pattern is to key on the session and treat the email as data hanging off it. See Best practices.