ForjioHuudisIdentityPlugipayPaymentsStorlaunchE-commerceFulkrumaFulfilmentRiplloMarketingLinkSnapShort URLsPawpadoGPU streamingCatentioAgent runtime
Huudis Docs
⌘K

huudis.session.created.v1

Fires when a new session is minted for a user — whether that's a Huudis cookie session (someone signed into the Huudis dashboard) or an OIDC session (someone signed into one of your clients).

Subscribe if you want a real-time "sign-in stream" for security analytics, anomaly detection, or new-device email notifications.

Not yet emitted in v1. The audit log carries auth.login and auth.session_issued entries.

When it fires

In every code path that creates a Session row:

  • Password sign-in via /v1/auth/login.
  • Social sign-in callback (/v1/auth/google/callback etc.).
  • OIDC token exchange (/v1/oidc/token — minting an access token implicitly creates a session record).
  • Device-flow code exchange (/v1/oidc/token with grant_type=device_code).
  • Impersonation start (/v1/ops/end-users/:id/impersonate).

Payload

{
  "id": "evt_01KPG…",
  "type": "huudis.session.created.v1",
  "createdAt": "2026-05-12T22:01:11.000Z",
  "data": {
    "sessionId": "sess_01KPG…",
    "userId": "usr_01KPG…",
    "userEmail": "adi@forjio.com",
    "clientId": "oc_plugipay_portal",
    "mfaVerified": true,
    "amr": ["pwd", "totp"],
    "ipAddress": "203.0.113.5",
    "userAgent": "Mozilla/5.0 (X11; Linux x86_64) …",
    "impersonatedById": null,
    "createdAt": "2026-05-12T22:01:11.000Z",
    "expiresAt": "2026-05-26T22:01:11.000Z"
  }
}
Field Meaning
clientId null for Huudis dashboard sessions; otherwise the OIDC client's client_id.
amr Authentication methods reference. Possible values: pwd, totp, webauthn, google, apple, facebook, device_code.
impersonatedById Set when an admin started an impersonation session on behalf of an end user.

Handler examples

// Node — flag suspicious IPs
if (event.type === 'huudis.session.created.v1') {
  const s = event.data;
  if (await ipReputation.isFlagged(s.ipAddress)) {
    await alerts.notify(`Suspicious sign-in for ${s.userEmail} from ${s.ipAddress}`);
  }
}

# Python — new-device notifications
if event["type"] == "huudis.session.created.v1":
    s = event["data"]
    if not seen_before(s["userId"], s["userAgent"], s["ipAddress"]):
        send_new_device_email(s["userEmail"], s["userAgent"], s["ipAddress"])
        remember(s["userId"], s["userAgent"], s["ipAddress"])

What to do

  • Drive "new device" notification emails by hashing (userAgent, ipAddress) and looking up against the user's history.
  • Feed an anomaly-detection pipeline — sudden volume from a single user, geographic jumps, etc.
  • Tag your own session table with the sessionId so you can later correlate with the audit log.

Avoid:

  • Treating this as "the user is now actively using your product." A session can be created and idle for days. Subscribe to product-specific activity events for that.
  • Counting it toward MAU. The MAU computation in billing uses lastUsedAt, not session-created.

Common pitfalls

  • Double-counting impersonations. An impersonation session looks just like a regular session but carries impersonatedById. Exclude impersonations from "real user sign-in" funnels.
  • Refresh vs. create. Refreshing a token does not fire a new session.created.v1 — the session row is the same. Refreshes are captured by huudis.session.refreshed.v1 (reserved, not yet emitted).

Next