Events and Event Hub

Only one event type is emitted today

Today the Event Hub emits a single event type, ClaimValuesChanged - it tells your Application that a user changed one or more of the claims you receive (for example, their name), so you can refresh your stored copy. Every other event type described on this page is planned and not emitted yet. Do not build logic against any other type until you have confirmed it with LuxID.

What is the Event Hub?

The LuxID Event Hub is the time-ordered stream of identity-relevant events LuxID generates for your partnership's Applications.

It covers a user signing in, a Subscription being created or revoked, consent changes, password and MFA changes, risk escalations, and similar lifecycle moments.

Events give your application visibility into the identity lifecycle without polling the UserInfo endpoint or maintaining your own copy of user state.

Why use it?

• Timely security response. A risk-escalation event lets your application require step-up MFA, block a transaction, or alert your security team within seconds.
• Consent lifecycle tracking. A consent-revocation event lets you delete or quarantine personal data in line with GDPR Article 17.
• Subscription management. Subscription create/revoke events let you provision and deprovision access in real time rather than waiting for the next sign-in.
• Audit and compliance. Every event carries a stable identifier, a timestamp and contextual fields - forward them to a SIEM for a complete identity audit trail.

The event envelope

Every event shares a common envelope. Beyond the common fields, each event carries a payload whose shape depends on the event's type and version:

{
  "id": "evt-01HKR8C5Z3...",
  "timestamp": "2026-05-15T09:23:11Z",
  "type": "ClaimValuesChanged",
  "version": "1",
  "sphere": "MyApp",
  "subscriber": "sub-user-42",
  "application": "app-abc-123",
  "subscription": "sub-app-abc-123-user-42",
  "payload": { "changedClaims": ["name"] }
}

Field	Notes
id	Stable unique identifier for the event. Use it as the idempotency / dedup key.
timestamp	When LuxID generated the event (ISO 8601). The canonical event time - your receipt time may be slightly later.
type	The kind of event. Determines what payload carries.
version	Schema version of payload for this type.
sphere, subscriber, application, subscription	Optional context fields, filled in when applicable. Use them to scope your reaction.
payload	Type-specific data. Treat as an object and handle missing fields defensively.

This is the same envelope used by both delivery models below. The authoritative envelope reference is the Partner API - Event Hub page.

Delivery: pull or push

LuxID exposes the same event stream through two complementary delivery models. Pick the one that fits your back-end.

Model	How it works	Where it is documented
Pull (Event Hub)	Your back-end polls a time-range query endpoint (GET /events/search) and reads events from the response. You control cadence and back-pressure, and can back-fill history on demand.	Partner API - Event Hub
Push (Webhooks)	LuxID POSTs each event to a URL you host, signed for verification. Lower latency, but your endpoint must stay highly available.	Webhooks and events API

You can use both: for example, webhooks for low-latency consent-revocation reactions and the pull Event Hub for nightly audit reconciliation. Either way, process events idempotently keyed on id.

Event catalogue

Currently emitted

Event type	Emitted when
ClaimValuesChanged	A user changed one or more of the claims your Application receives (for example, their name). Use it to refresh your stored copy of the user's profile.

Planned (not emitted yet)

The event types below are identity lifecycle moments LuxID intends to emit in future. They are not available today - treat them as a roadmap, not a contract. The authoritative list and payload shapes will be maintained in the LuxID OpenAPI document; confirm with your LuxID Account manager before relying on any of them.

Event type	Emitted when
user.created	A user completes account registration and the account becomes active
user.signed_in	A successful authentication to your Application
user.signed_out	A user ends their LuxID session
user.deleted	A user permanently deletes their LuxID Account - treat subscriber as retired and erase or anonymise their data
user.consent.granted	A user grants consent for your Application to receive claims
user.consent.revoked	A user withdraws consent for your Application
user.password.changed	A user changes or resets their password
user.password.breach_detected	A breached password is detected (see Breached password detection)
user.mfa.method_added	A user adds an MFA method
user.mfa.method_removed	A user removes an MFA method
user.risk.escalated	The risk engine classifies a sign-in above baseline (see Security signals and risk scoring)
user.identity.verified	A user completes LuxID Verified identity proofing
subscription.created	A user connects your Application for the first time
subscription.revoked	A user removes their connection to your Application

SIEM integration

The Event Hub is designed to feed identity signals into your SIEM. Recommended practices:

• Forward the full lifecycle, not just risk events - context matters (a user.signed_in moments after a user.password.changed from a different IP is a meaningful signal).
• Correlate on subscriber within your application: it matches the sub in your tokens, letting you join identity events with your own audit log.
• Do not correlate across applications. The subject identifier is Sphere-scoped - two applications in different Spheres see different values for the same user.
• Deduplicate on id - both delivery models can deliver the same event more than once.
• Retain timestamp as the canonical event time.

Related pages

• Partner API - Event Hub - the pull query interface and canonical envelope reference.
• Webhooks and events API - push delivery, signing and replay protection.
• Revocation - acting on subscription and consent revocation events.
• Logs and audit trails - Console visibility for events.