Event reference

This is the full event catalogue. New events are added with new minor versions of the platform; existing payload shapes are append-only — your code can rely on existing fields staying put.

The envelope is documented in the overview. This topic covers what's in the data field for each event type.

Auth events

`user.signed_in`

A user successfully completed sign-in (with or without MFA).

{
  "event_type": "user.signed_in",
  "data": {
    "user": { "id": "usr_01HZ...", "email": "anita@cymmetri.com", "name": "Anita Singh" },
    "session": { "id": "ses_01HZ...", "amr": ["pwd", "webauthn"], "acr": "aal2" },
    "application": { "id": "app_01HZ...", "name": "Banking Web" },
    "request": { "ip": "203.0.113.45", "user_agent": "Chrome 132 on macOS" }
  }
}

`user.signed_out`

The user (or an admin) revoked the session.

{
  "event_type": "user.signed_out",
  "data": {
    "user":    { "id": "usr_01HZ..." },
    "session": { "id": "ses_01HZ..." },
    "reason":  "user_initiated"
  }
}

reason is one of user_initiated, admin_revoked, idle_timeout, policy_violation.

`user.sign_in_failed`

A sign-in attempt did NOT succeed. Useful for security analytics.

{
  "event_type": "user.sign_in_failed",
  "data": {
    "email_submitted": "mal@evil.example",
    "error_code":      "invalid_credentials",
    "request":         { "ip": "203.0.113.45", "user_agent": "..." }
  }
}

Note: user.id is absent — the failure may not correspond to a real user.

`user.mfa_required`

A sign-in reached the MFA step.

{
  "event_type": "user.mfa_required",
  "data": {
    "user":              { "id": "usr_01HZ..." },
    "available_factors": ["webauthn", "totp"],
    "reason":            "policy"
  }
}

`user.mfa_succeeded` and `user.mfa_failed`

Outcomes of the MFA step.

{
  "event_type": "user.mfa_failed",
  "data": {
    "user":   { "id": "usr_01HZ..." },
    "factor": { "kind": "totp" },
    "reason": "code_invalid"
  }
}

User lifecycle

`user.signed_up`

A new user record exists. Fires once per user, on creation.

{
  "event_type": "user.signed_up",
  "data": {
    "user": {
      "id": "usr_01HZ...",
      "email": "anita@cymmetri.com",
      "name": "Anita Singh",
      "email_verified": false,
      "source": { "kind": "social", "provider": "google" }
    }
  }
}

source.kind is one of password, social, saml, oidc, admin_invite, bulk_import.

`user.updated`

A user record was patched. The payload includes only the fields that changed.

{
  "event_type": "user.updated",
  "data": {
    "user":    { "id": "usr_01HZ..." },
    "changed": { "name": "Anita S.", "attributes": { "department": "engineering" } },
    "actor":   { "kind": "admin", "id": "usr_01HZA..." }
  }
}

`user.disabled`, `user.enabled`

Soft state changes.

{
  "event_type": "user.disabled",
  "data": {
    "user":  { "id": "usr_01HZ..." },
    "actor": { "kind": "admin", "id": "usr_01HZA..." },
    "reason": "off_boarding"
  }
}

`user.deleted`

Hard delete. The payload carries the last-known user fields because the record no longer exists.

{
  "event_type": "user.deleted",
  "data": {
    "user":  { "id": "usr_01HZ...", "email": "anita@cymmetri.com" },
    "actor": { "kind": "admin", "id": "usr_01HZA..." }
  }
}

`user.email_verified`

{
  "event_type": "user.email_verified",
  "data": { "user": { "id": "usr_01HZ...", "email": "anita@cymmetri.com" } }
}

MFA factor lifecycle

`mfa.factor_added`

{
  "event_type": "mfa.factor_added",
  "data": {
    "user":   { "id": "usr_01HZ..." },
    "factor": { "id": "factor_01HZ...", "kind": "webauthn", "label": "MacBook Pro" }
  }
}

`mfa.factor_removed`

{
  "event_type": "mfa.factor_removed",
  "data": {
    "user":    { "id": "usr_01HZ..." },
    "factor":  { "id": "factor_01HZ...", "kind": "totp" },
    "removed_by": { "kind": "user" }
  }
}

`mfa.backup_codes_regenerated`

{
  "event_type": "mfa.backup_codes_regenerated",
  "data": { "user": { "id": "usr_01HZ..." }, "count": 10 }
}

Application admin

`application.created`

{
  "event_type": "application.created",
  "data": {
    "application": { "id": "app_01HZ...", "name": "Mobile iOS", "type": "native" },
    "actor": { "kind": "admin", "id": "usr_01HZA..." }
  }
}

`application.updated`

{
  "event_type": "application.updated",
  "data": {
    "application": { "id": "app_01HZ..." },
    "changed":     { "redirect_uris": [...] },
    "actor": { "kind": "admin", "id": "usr_01HZA..." }
  }
}

`application.secret_rotated`

{
  "event_type": "application.secret_rotated",
  "data": {
    "application":       { "id": "app_01HZ..." },
    "previous_expires_at": "2026-05-20T10:00:00Z",
    "actor": { "kind": "admin", "id": "usr_01HZA..." }
  }
}

The new secret itself is NEVER in the webhook payload — only the rotation event.

`application.disabled`, `application.deleted`

Same shape as their user-side counterparts.

Federation

`federation.connection_added`, `federation.connection_disabled`, `federation.connection_deleted`

{
  "event_type": "federation.connection_added",
  "data": {
    "connection": { "id": "fed_01HZ...", "kind": "saml", "slug": "cymmetri-okta" },
    "actor":      { "kind": "admin", "id": "usr_01HZA..." }
  }
}

`federation.sso_completed`, `federation.sso_failed`

Outcomes of a federated sign-in. The connection field tells you which IdP was involved; user is present on completed, absent on failed (if no user matched).

Security

`security.brute_force_detected`

Triggered when the platform's risk engine sees a pattern of failed attempts.

{
  "event_type": "security.brute_force_detected",
  "data": {
    "target_email_or_user": "anita@cymmetri.com",
    "attempt_count":        17,
    "window_seconds":       300,
    "ips":                  ["203.0.113.45", "203.0.113.46"]
  }
}

Wire this to your incident response — alert on it, block the IPs at your edge, surface to the user via a "we noticed something" email.

`security.token_reuse_detected`

A rotated refresh token was used twice. Strong signal of token leakage.

{
  "event_type": "security.token_reuse_detected",
  "data": {
    "user":         { "id": "usr_01HZ..." },
    "session_id":   "ses_01HZ...",
    "first_seen_ip": "203.0.113.45",
    "second_seen_ip": "198.51.100.22"
  }
}

The platform automatically invalidates the token family; this event is informational.

`security.breach_incident_opened`

A breach incident record was created — typically from an external feed indicating one of your users' credentials appeared in a public dump.

{
  "event_type": "security.breach_incident_opened",
  "data": {
    "incident_id":   "inc_01HZ...",
    "affected_user": { "id": "usr_01HZ..." },
    "source":        "haveibeenpwned",
    "severity":      "high"
  }
}

The full incident lifecycle is operated by tenant admins in the IntelliAuth admin console — read + resolve happens there. As an integrator, you receive this webhook and can drive your own incident response (alert your security channel, force-rotate downstream credentials, etc.).

Event reference

Auth events

user.signed_in

user.signed_out

user.sign_in_failed

user.mfa_required

user.mfa_succeeded and user.mfa_failed

User lifecycle

user.signed_up

user.updated

user.disabled, user.enabled

user.deleted

user.email_verified

MFA factor lifecycle

mfa.factor_added

mfa.factor_removed

mfa.backup_codes_regenerated