メインコンテンツに移動

Session.ApproverEmailUpdate

保護者がk-IDアカウントのメールアドレスを変更したときに、そのアドレスが同意を与えている子どもごとに1件ずつ発行されます。ペイロードには変更前と変更後の両方のアドレスが含まれるため、すでに保持しているレコードをこのイベントだけで特定して更新できます。

セッションはそれ以外の点では変更されません。ACTIVEのまま、同じsessionIdと権限を保持し、子どもは中断なく利用を続けられます。移動するのは、k-IDがその子どもの今後のチャレンジ、承認、通知を送信する先のアドレスだけです。

このイベントを購読してください

ウェブフックのエンドポイントが受け取れるのは、購読しているイベントタイプだけです。Compliance StudioのプロダクトのDeveloper Settingsページで、対象のエンドポイントにSession.ApproverEmailUpdateを選択してください。選択しない限り、k-IDは配信も試みずエラーも返さずにこのイベントを破棄します。この項目は、組織で保護者のメールアドレス変更が有効になっている場合にのみ一覧に表示されます。

配信とリトライ

ウェブフックイベントは、失敗時に最大2回リトライされます。詳しくは配信、リトライ、リカバリーを参照してください。

発行されるタイミング​

保護者はFamily Connectからメールアドレスの変更を開始し、新しいアドレスに送られるワンタイムコードで確認します。変更を確定すると、k-IDは各子どものセッションを新しいアドレスに向け直し、子どものセッションごとにSession.ApproverEmailUpdateを1件発行します。

  • 子どもごと、プロダクトごとに1件。 あなたのプロダクトに3人の子どもがいる保護者なら3件のイベントが発生し、それぞれ異なるidと、同一のoldEmailおよびnewEmailを持ちます。
  • アクティブなセッションを持つ子どものみ。 あなたのプロダクトにアクティブなセッションがない子どもには向け直す対象がないため、イベントは発行されません。その子どもが後からセッションを取得する場合、そのセッションは新しいアドレスに対して作成されます。
  • 確定操作で発行されるのは1回だけ。 k-IDが向け直すのは承認者がまだoldEmailであるセッションだけなので、確定をリトライしても、すでに移動済みの子どもについて2件目のイベントが発行されることはありません。ただし配信は少なくとも1回の保証であるため、ハンドラーは冪等に保ってください。

フィールド​

フィールド型必須説明
eventTypestringはい常に"Session.ApproverEmailUpdate"
dataobjectはいメールアドレス変更の詳細
data.idstring (UUID)はいあなたのプロダクトにおける、その子どものセッションのセッションID
data.productIdnumberはいプロダクトのproductId
data.oldEmailstringはい保護者が変更前に使用していたアドレス
data.newEmailstringはい保護者が変更後に使用するアドレス。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を持つイベントは何もしない処理になるべきです。
  • セッションではなく保護者のメールアドレスをキーにしている箇所がある場合、そのキーが古くなるのを防ぐのがこのイベントです。より堅牢なパターンは、セッションをキーにし、メールアドレスはそこに紐づくデータとして扱うことです。ベストプラクティスを参照してください。