huudis.user.enabled.v1

Fires when a previously disabled Huudis user is re-enabled. Counterpart to huudis.user.disabled.v1.

Not yet emitted in v1. Audit log carries ops.end_user.enabled entries with the same data.

When it fires

When POST /v1/ops/end-users/:id/enable succeeds. The user's disabled flag flips back to false; future sign-ins work normally.

Re-enabling does not restore the user's previous sessions or refresh tokens — they were revoked at disable time and stay revoked. The user must sign in again from scratch.

Payload

{
  "id": "evt_01KPG…",
  "type": "huudis.user.enabled.v1",
  "createdAt": "2026-05-12T11:00:00.000Z",
  "data": {
    "id": "usr_01KPG…",
    "email": "user@example.com",
    "enabledAt": "2026-05-12T11:00:00.000Z",
    "enabledBy": "usr_01KPG30SP…"
  }
}

Handler examples

// Node
if (event.type === 'huudis.user.enabled.v1') {
  const u = event.data;
  await db.users.update(u.id, { disabled: false });
  // The user can now sign in again — no need to restore old sessions;
  // they will mint fresh ones.
}
# Python
if event["type"] == "huudis.user.enabled.v1":
    db.users.update(event["data"]["id"], disabled=False)

What to do

  • Flip your own user's disabled flag back to false.
  • If you alerted on-call during the original disable, post a follow-up "user re-enabled" note for closure.

Avoid:

  • Restoring old session data. The user explicitly needs to re-authenticate; pretending nothing happened erases the access-control reset that's the point of the disable cycle.

Common pitfalls

  • Race with disable. Disable + enable in quick succession is supported, but the second event might arrive at your endpoint before the first — deliveries aren't strictly ordered. Check enabledAt > disabledAt before deciding the user is currently usable; or just upsert the latest state and let it settle.
  • Forgetting MFA was lost. If the user lost their MFA device while disabled, they may struggle to sign in. Provide a support path; the disable/enable cycle alone doesn't reset MFA enrolment.

Next