ForjioHuudisIdentityPlugipayPaymentsStorlaunchE-commerceFulkrumaFulfilmentRiplloMarketingLinkSnapShort URLsPawpadoGPU streamingCatentioAgent runtime
Huudis Docs
⌘K

huudis.user.disabled.v1

Fires when a Huudis user is globally disabled — suspended across every workspace they belong to and every OIDC client they've consented to. Reserved for Forjio-internal ops (the user-disable endpoint requires the special huudis Forjio-internal workspace). Use this event to cut off downstream access immediately.

Not yet emitted in v1. The audit log carries ops.end_user.disabled entries with the same data.

When it fires

When POST /v1/ops/end-users/:id/disable succeeds. Internally, this:

  • Sets disabled = true on the user row.
  • Revokes every live session.
  • Revokes every refresh token across every OIDC client.

A disabled user cannot sign in to any Forjio product. Existing access tokens stay valid until they naturally expire (typically ≤1 hour); refresh attempts fail with invalid_grant.

Payload

{
  "id": "evt_01KPG…",
  "type": "huudis.user.disabled.v1",
  "createdAt": "2026-05-12T10:42:00.123Z",
  "data": {
    "id": "usr_01KPG…",
    "email": "abuser@example.com",
    "disabledAt": "2026-05-12T10:42:00.000Z",
    "disabledBy": "usr_01KPG30SP…",
    "reason": "policy_violation"
  }
}

reason is a Forjio-operator-supplied tag if the disable was annotated; otherwise omitted.

Handler examples

// Node
if (event.type === 'huudis.user.disabled.v1') {
  const u = event.data;
  // Cut their access in our own service immediately.
  await db.users.update(u.id, { disabled: true });
  await session.revokeAllForUser(u.id);
  await pager.notify(`User ${u.email} disabled — outbound access cut.`);
}

# Python
if event["type"] == "huudis.user.disabled.v1":
    u = event["data"]
    db.users.update(u["id"], disabled=True)
    session.revoke_all(u["id"])

What to do

  • Mark the user as disabled in your own user table (or delete their row, if your model treats Huudis as source of truth).
  • Revoke any sessions, tokens, or cached credentials your service holds for the user.
  • Notify on-call if the disable came from an automated abuse pipeline — sometimes legitimate users get caught by false positives.

Avoid:

  • Sending notification emails to the user. They've been disabled — spamming them is wrong-shaped, and the email address may itself be the issue.
  • Cascading the disable to other users (e.g. "anyone who emailed this person"). Stay narrow.

Common pitfalls

  • Race with already-issued access tokens. The user can still make API calls for ≤1 hour with existing access tokens. Cross-reference the user-disabled flag in your own auth middleware, not just at session start.
  • Cross-workspace ripple. Disabling cuts the user across every workspace they belong to, including any your service has as a paying customer. If a customer's primary admin gets disabled, their entire workspace stops being administrable.

Next